On Apr 16, 2009 at 17:14, Henning Westerholt henning.westerholt@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@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