Re: problem when pulling a specific branch from origin
Hi Konstantin,
Thanks for your thorough answer.
Konstantin Khomoutov <flatworm@users.sourceforge.net> wrote:
Show 10 quoted lines
> 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.
Show 7 quoted lines
> 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?
Show 17 quoted lines
> 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