[SR-Dev] git:master: Merge ssh://git.sip-router.org/sip-router into my_branch

[Henning Westerholt]

On Monday 24 November 2008, Andrei Pelinescu-Onciul wrote:
> > > Henning did you forgot to set  merge log to true in your git config
> > >  (~/.gitconfig or per repository in  .git/config)?
> > > ( git config --get  merge.log  # to see it's value
> > >   git config --global merge.log true  # to set it to true)
> >
> > i'm still trying to wrap my head around this git. ;-) Aparently this
> > merged the content from the henning/trie branch into the trunk, the
> > operation i wanted to do. But i don't understand the log message,
> > 'my_branch' is a local branch on my machine, not sure why this show up,
> > and it should be also the other way round. And the diff for the revision
> > is also the other way round.
> >
> > Perhaps i just did it the wrong way. :-/
> >
> > henning at ca:~/projects/openser/sip-router$ git config --get  merge.log
> > true
> >
> > Perhaps it make sense to revert this commit?
>
> No, the commit is ok, only the last log message is broken.
>
> You probably where on "my_branch" and you did a
>  git pull ssh://git.sip-router.org/sip-router master
> and then
>  git push origin my_branch:master
>
> So what you did was to merge the remote version of  master into "my_branch"
> and then update master with my_branch version.

Hi Andrei,

yes, correct. I read on some git docs that this is needed in order to merge 
the branches. This were apparently wrong.

> What you should have done is to merge trie or "my_branch" into master:
>
> git fetch origin # to get up-to-date origin/ branches, including master
> git checkout -b master origin/master # local branch following
>                                      # origin/master
> # now you are on branch master (local version)

Ah, ok, understand.

> git merge trie
> git log  or gitk to see if everything looks ok
> git push origin master:master

Ok

> If you already have a local master branch tracking origin/master you
> could do instead:
> git checkout master # switch to master
> git pull origin master # equiv. with git fetch origin; git merge master
> git merge trie
> # git log or gitk to see if everything looks ok
> git push origin master:master

I'll try this the next time, perhaps in the test branch.

> Note that some of this commands have shorter forms (if not specified some
> parameters take some default values and some of this values can be
> configured in the git config on a per branch basis, e.g. the default
> branch to push into or to pull form).
>
> Note2: you don't have to specify the whole reop name path
>  (ssh://git.sip-router.org/sip-router), origin is set by default to the
>  repo from where you cloned, so you could always use origin.

Ah, good to know!

> To revert the commit (it's not needed since we have only a strange merge
> message, but the rest is ok, but it might be good practice), there are 2
> possibilities:
>
> 1. you could use git revert (it will create a new commit reverting the
>   old one):
>   checkout the master branch:
>    - if you don't have a local master:
>      git fetch origin; git checkout -b master origin/master
>    - if you already have a master tracking origin/master (created in a
>      similar way some time ago):
>       git checkout master # switch to master
>       git pull origin master
>   revert the commit
>     git revert  -m X commit_id
>      where comit_id is the commit you want reversed (in this case
>       8d41196809f014e00346785b6517bd2c4051901a)  and X is the merge
>       parent number that should be the mainline (in this case I think
>       it's 2)
>     You could try
>      git revert --no-commit -m 2 8d41196809f014e00346785b6517bd2c4051901a
>     and see if it look ok (and if it does remove --no-commit and retry).
>
>   After this and after making sure the log looks ok (gitk, or git log)
>   you can git push origin master:master, or maybe git push origin
>   master:tmp/test just to have an extra check.
>   WARNING: do not push if it doesn't look ok (if you use the wrong -m
>   value you might end up reverting master into your branch :-)).
>
> 2. we could revert it the hard way without leaving "commit" traces
>  (by directly editing the master branch on sip-router.org and making it
>   point to the previous comit). The problem with this is that if people
>   have already checked out the current master version they will have
>   problems updating, but since I don't expect to have more then 2 or 3
>   people who do this at this point we could try it as an experiment
>   (in the future we might have to revert a commit the hard way so we
>    might try it now when this will not cause any serious problems).

I'll try the first method. Thanks for your help and explanations,

Henning