Hi Konstantin, Thanks for your thorough answer. Konstantin Khomoutov <flatworm@xxxxxxxxxxxxxxxxxxxxx> wrote: > The first one is that you seem to maintain a wrong idea about what > happens when you do `git pull origin branch`. It appears you assume > this action is supposed to first update the local branch > "remotes/origin/branch" and then merge it to the locally checked out > branch. The truth is that specifying a branch in this way to git-pull > (or git-fetch, which is called by git-pull) is a special case -- it > means that no corresponding local ref is updated, and the fetched line > of history is directly merged into the checked out branch right after > fetching (see the git-fetch manual and the EXAMPLES section in the > git-pull manual). You're right I get the wrong idea of pull origin branch, it's a special case and it doesn't update local ref. > I'm not really sure about your expectation as you did not clearly > articulate them, so it seems there are two points to touch here... I expect my local ref to be updated with the server ref. > In your particular case you're merging remote branch "branch" which is > one commit ahead of remote "master" to the locally checked branch > "master" which is, at the moment, the same as the same-named remote > branch. Consequently, after merging "branch" (which results in > fast-forward) your local branch "master" starts to be one commit ahead > of its remote counterpart; no local branches beyond this one are > updated. I forgot to checkout the branch in the repository bar, I have attached the updated script. The result is the same my branch is one commit ahead. If we run git fetch without argument the refs are updated: yan:~/tmp/bar$ git fetch >From /home/ivan/tmp/foo 6fe0a63..ebcae31 branch -> origin/branch However running fetch without arguments pull all remote refs which my developer does not want. Is there a command to update a specific remote ref? > The second point is less clear/more complicated. > At first, it's not clear whether you wanted to have the remote branch > "branch" become the active local branch during the cloning process, or > "master" (in your case "master" became the active branch). > On the one hand, you explicitly branched "branch" off "master" right > before cloning (updating the first repo's HEAD ref) which hints you > intended that branch to be default in the clone. > On the other hand, while the documentation says the default branch in > the clone is the one listed in the HEAD ref of the source repository, in > my tests using Git (1.7.2.x in Debian and msysgit 1.7.3.x), in cases > like yours the destination repository ends up having the "master" branch > as the default one, not the branch from the HEAD ref; to make this work, > the branch listed in the HEAD ref should have received at least one > commit after forking. I suspect the problem might be in that such a > branch freshly cloned off "master" points to the same commit object's > name which might confuse Git. > This, in my eyes, might indeed display a bug. The current behavior is a bit weird to say the least, I don't know if it's a bug. Take care, -- Ivan Kanis http://kanis.fr At Group L, Stoffel oversees six first-rate programmers, a managerial challenge roughly comparable to herding cats. -- Anonymous , 1985-06-09 , The Washington Post
#!/bin/sh rm -rf foo bar git --version mkdir foo cd foo git init echo foo > foo.txt git add foo.txt git commit -am"foo" git checkout -b branch cd .. git clone foo bar cd foo echo bar > foo.txt git commit -am"bar" cd .. cd bar git checkout branch git pull origin branch git status git branch -rv