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

[Andrei Pelinescu-Onciul]

On Nov 24, 2008 at 20:45, Andrei Pelinescu-Onciul <andrei at iptel.org> wrote:
> On Nov 24, 2008 at 19:46, Henning Westerholt <henning.westerholt at 1und1.de> wrote:
> > On Monday 24 November 2008, Andrei Pelinescu-Onciul wrote:
> > > On Nov 24, 2008 at 19:29, Henning Westerholt <henning.westerholt at 1und1.de> 
> > wrote:
> > > > Module: sip-router
> > > > Branch: master
> > > > Commit: 8d41196809f014e00346785b6517bd2c4051901a
> > > > URL:   
> > > > http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=8d411
> > > >96809f014e00346785b6517bd2c4051901a
> > > >
> > > > Author: Henning Westerholt <henning.westerholt at 1und1.de>
> > > > Committer: Henning Westerholt <henning.westerholt at 1und1.de>
> > > > Date:   Mon Nov 24 19:13:59 2008 +0100
> > > >
> > > > Merge ssh://git.sip-router.org/sip-router into my_branch
> > >
> > > That should have been:
> > >
> > >  Merge commit 'origin/henning/trie' into master
> > >
> > >  * commit 'origin/henning/trie':
> > >    add trie to library directory
> > >    add SHM_MEM_ERROR and PKG_MEM_ERROR logging macros to mem.h
> > >
> > >
> > >
> > > 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)
> > 
> > Hi Andrei,
> > 
> > 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.
> 
> 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)
> git merge trie
> git log  or gitk to see if everything looks ok
> git push origin master:master
> 
> 
> 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
> 
> 
> 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.
> 
> 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).

Just for reference, you could do it without any editing on
 sip-router.org if we would allow non fast forward updates (right
 now they are disabled globally):

 git checkout master 
 git pull origin master  # make sure we have an up-to-date ver.
 git log --pretty=oneline -5 # look at the summary of the last 5 commits
# we see that we want to reverse the last commit (the one just on top)

# try reverting to parent 1 (since this particular commit is a merge, it
# has 2 parents instead of 1); if we look at gitk or at the more
# detailed log  or think on how we merged in the first place we can find out
# that the second parent is the correct answer, but let's assume we
# are in a hurry and we try all options

git reset --hard HEAD^1  # warning: will loose all local non-committed
                         # changes (see git help reset)
HEAD is now at 99d1967 add trie to library directory

# this is not good, we reverted to the wrong parent
# => undo the changes

git reset --hard ORIG_HEAD
git log --pretty=oneline -5 # make sure we properly undo'ed
# try the second parent
git reset --hard HEAD^2
HEAD is now at 7e69be0 Merge commit 'origin/andrei/fixups'
# look ok

git log --pretty=oneline -5 # just to be sure  (not really needed)

git push origin +master:master # do non-fast forward update

# the last git push is equivalent to login in sip-router.org
# ,editing refs/heads/master in the sip-router repo and setting it
# to 7e69be0441a98653ea0d94c831f64a2947aa4fff
# the '+' forces a non-fast forward update (but right now is disabled
# on sip-router.org)

After a non fast forward update to a public branch, all the people who
pull'ed out the version just before the update/revert have a problem:
they won't see the revert. 
In our particular case this is not a problem, since after the revert we
would commit the same thing with another merge message, however
in general all the people who pulled in the time window before 
the revert should do one of:

- git fetch origin; git reset --hard FETCH_HEAD  if they don't have
  _any_ local changes that they care about (reset --hard will destroy
   all local changes)
- git fetch origin; git rebase  FETCH_HEAD  (local changes are not lost)


Andrei