[SR-Dev] [Serdev] Git Crash Course For sip-router

[Andrei Pelinescu-Onciul]

On Apr 16, 2009 at 17:14, Henning Westerholt <henning.westerholt at 1und1.de> wrote:
> On Thursday 16 April 2009, Jan Janak wrote:
> > > No, it's not normal (I've never seen it). You should not see anything in
> > > git diff after a git pull, if you haven't made any local changes (you
> > > should see only local changes).
> > > Same for git status (you should see only local changes or untracked
> > > files).
> >
> > Now I realize that Henning was probably asking something else. Yes, what
> > Henning describes can happen if you use --no-commit (which was on by
> > default for the master branch in one of my .giconfig files).
> >
> > In this case git pull performs the merge but does not commit it, so you end
> > up with modified files in the branch and you have to run git ci to commit
> > them.
> >
> > I had this option turned on in the first .gitconfig I circulated, because I
> > found it useful when I was merging changes from the svn repository into
> > kamailio-3.0. In the second .gitconfig file (attached to the crash-course
> > email) this option is already commented out.
> 
> Hi Jan,
> 
> yes, this is it!
> 
> git-config -l |grep "no-commit"
> branch.master.mergeoptions=--no-commit --no-ff
                                         ^^^^^^^
                                       This is debatable too.
> 
> This is probably related to another problem i've got, after the remote 
> repository changed and i've tried to push my changes back:
> 
> henning at ca:~/projects/openser/sip-router$ git push -v
> Pushing to ssh://git.sip-router.org/sip-router
> To ssh://git.sip-router.org/sip-router
>  ! [rejected]        master -> master (non-fast forward)
> error: failed to push some refs to 'ssh://git.sip-router.org/sip-router'

Probably. In a normal case you would use either git rebase origin/master
 and then retry the push or git pull --ff origin/master and retry the
 pull (but since you used  --no-commit, I don't know in what state you
 have your master branch so it might be dangerous, if you really want to
 try it, backup and try pushing to some tmp test branch, e.g. git push
 origin tmp/test).

Regarding --no-ff: sometimes is good (when merging some
branch into master), ortherwise produces confusing merge messages
 (when updating master from origin/master with git pull origin master).

I think is much better to explicitely specify --ff and --no-ff each time
you do a merge into master or a pull into _master_:

git pull --ff origin/master # always use fast forward when updating
                            # master from the repository

git merge --no-ff origin/some_branch # always use non-fast-forward when
                                     # merging some branch into master

(--no-ff force a merge message even if the merge was a fast-forward,
which is very helpfull to track merges with other branches)


Andrei