git pull versus fetch/merge

git pull versus fetch/merge

[Rene Herman]

Good day.

A while ago I was here asking about "git pull" versus "git merge" for 
local branches -- now I see a difference for remote ones that I'm not 
sure should be there.

I gathered before that "git pull <remote> <branch>" should basically be 
shorthand for "git fetch <remote>, git merge <remote>/<branch>". Is that 
correct?

I'm seeing a problem I believe with a specific repository:

rene@7ixe4:~/src/linux/7ixe4$ git remote show tiwai
* remote tiwai
   URL: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
   Tracked remote branches
     devel dma-fix for-linus master upstream

with "git pull tiwai devel" everything goes well:

rene@7ixe4:~/src/linux/7ixe4$ git status
# On branch master
nothing to commit (working directory clean)
rene@7ixe4:~/src/linux/7ixe4$ git branch tmp0 v2.6.26
rene@7ixe4:~/src/linux/7ixe4$ git branch tmp1 v2.6.26
rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp0
Switched to branch "tmp0"
rene@7ixe4:~/src/linux/7ixe4$ git pull tiwai devel
Updating bce7f79..e0bf09b
Fast forward
  Documentation/sound/alsa/ALSA-Configuration.txt    |   17 +-
  [ ... ]

and I get a clean merge. On the other hand, if I try to do this with a 
fetch/merge, I get:

rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp1
Switched to branch "tmp1"
rene@7ixe4:~/src/linux/7ixe4$ git fetch tiwai
 From git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
  ! [rejected]        devel      -> tiwai/devel  (non fast forward)
  ! [rejected]        dma-fix    -> tiwai/dma-fix  (non fast forward)
  ! [rejected]        master     -> tiwai/master  (non fast forward)
rene@7ixe4:~/src/linux/7ixe4$ git merge tiwai/devel
Auto-merged sound/pci/ac97/ac97_patch.c
Auto-merged sound/pci/emu10k1/emu10k1_main.c
Auto-merged sound/pci/hda/patch_analog.c
Auto-merged sound/pci/hda/patch_realtek.c
CONFLICT (content): Merge conflict in sound/pci/hda/patch_realtek.c
Auto-merged sound/pci/hda/patch_sigmatel.c
Automatic merge failed; fix conflicts and then commit the result.

and me no happy...

It probably has something to do with that " ! [rejected]" but what is 
that about? Is the repo bad? (and if so, I suspect owner will want to 
know how to avoid it in the future).

And if it is bad, should I be seeing something with the pull method 
also? Moreover... can I now trust my tmp0 branch?

Rene.

Re: git pull versus fetch/merge

[Björn Steinbrink]

On 2008.07.21 11:11:50 +0200, Rene Herman wrote:
> Good day.
>
> A while ago I was here asking about "git pull" versus "git merge" for  
> local branches -- now I see a difference for remote ones that I'm not  
> sure should be there.
>
> I gathered before that "git pull <remote> <branch>" should basically be  
> shorthand for "git fetch <remote>, git merge <remote>/<branch>". Is that  
> correct?
>
> I'm seeing a problem I believe with a specific repository:
>
> rene@7ixe4:~/src/linux/7ixe4$ git remote show tiwai
> * remote tiwai
>   URL: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
>   Tracked remote branches
>     devel dma-fix for-linus master upstream
>
> with "git pull tiwai devel" everything goes well:
>
> rene@7ixe4:~/src/linux/7ixe4$ git status
> # On branch master
> nothing to commit (working directory clean)
> rene@7ixe4:~/src/linux/7ixe4$ git branch tmp0 v2.6.26
> rene@7ixe4:~/src/linux/7ixe4$ git branch tmp1 v2.6.26
> rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp0
> Switched to branch "tmp0"
> rene@7ixe4:~/src/linux/7ixe4$ git pull tiwai devel
> Updating bce7f79..e0bf09b
> Fast forward
>  Documentation/sound/alsa/ALSA-Configuration.txt    |   17 +-
>  [ ... ]
>
> and I get a clean merge.

"git pull remote branch" does "git fetch remote branch". That only
fetches that single branch and stores it in FETCH_HEAD. The merge part
then merges what is in FETCH_HEAD into your current branch.

> On the other hand, if I try to do this with a  fetch/merge, I get:
>
> rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp1
> Switched to branch "tmp1"
> rene@7ixe4:~/src/linux/7ixe4$ git fetch tiwai
> From git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
>  ! [rejected]        devel      -> tiwai/devel  (non fast forward)
>  ! [rejected]        dma-fix    -> tiwai/dma-fix  (non fast forward)
>  ! [rejected]        master     -> tiwai/master  (non fast forward)

The rejected branches had their history rewritten since your last fetch.
Git rejects to update your remote tracking branches in that case. The
history rewriting might have been an accident, or it might have been
intentional. Only the owner of that repo is able to tell that.

You can use -f to force the updates.

> rene@7ixe4:~/src/linux/7ixe4$ git merge tiwai/devel
> Auto-merged sound/pci/ac97/ac97_patch.c
> Auto-merged sound/pci/emu10k1/emu10k1_main.c
> Auto-merged sound/pci/hda/patch_analog.c
> Auto-merged sound/pci/hda/patch_realtek.c
> CONFLICT (content): Merge conflict in sound/pci/hda/patch_realtek.c
> Auto-merged sound/pci/hda/patch_sigmatel.c
> Automatic merge failed; fix conflicts and then commit the result.
>
> and me no happy...
>
> It probably has something to do with that " ! [rejected]" but what is  
> that about? Is the repo bad? (and if so, I suspect owner will want to  
> know how to avoid it in the future).
>
> And if it is bad, should I be seeing something with the pull method  
> also? Moreover... can I now trust my tmp0 branch?

Your fetch/merge approach was different from what your pull approach
did. tiwai/devel did not get updated by the fetch, which means that you
tried to merge the old state of that branch and that caused some
conflicts. OTOH the pull did fetch the latest state from the remote repo
and merged that cleanly.

Your fetch/merge approach was more like "git pull" without any
arguments, but with the current branch setup to track tiwai/devel. In
that case, pull really does a "git fetch tiwai", and it should fail in
the same way.

Björn

Re: git pull versus fetch/merge

[Rene Herman]

On 21-07-08 12:23, Björn Steinbrink wrote:

> Your fetch/merge approach was different from what your pull approach 
> did. tiwai/devel did not get updated by the fetch, which means that
> you tried to merge the old state of that branch and that caused some 
> conflicts. OTOH the pull did fetch the latest state from the remote
> repo and merged that cleanly.
> 
> Your fetch/merge approach was more like "git pull" without any 
> arguments, but with the current branch setup to track tiwai/devel. In
> that case, pull really does a "git fetch tiwai", and it should fail
> in the same way.

Thank you. Also due to a reply on the ALSA list by Mark brown I now get 
this. Yes, the remote was rebased while I had it setup as a remote here 
it seems; only recently have it under this name, so I didn't think that 
was the case. After a "git remote rm tiwai, git remote add tiwai <url>" 
things work fine again as it fetched a completely new branch.

Hurray for rebasing public trees. This specific branch should be rebased 
only at every kernel release so I guess it's okay. I guess I can just do
the git pull always, or the fetch every time and let the reject warn me 
that it was rebased after which I'll do the remote rm/add thing again.

Many thanks for the concrete description of what goes on. Made it obvious.

Rene.

Re: git pull versus fetch/merge

[Jeff King]

On Mon, Jul 21, 2008 at 12:58:10PM +0200, Rene Herman wrote:

> Thank you. Also due to a reply on the ALSA list by Mark brown I now get  
> this. Yes, the remote was rebased while I had it setup as a remote here  
> it seems; only recently have it under this name, so I didn't think that  
> was the case. After a "git remote rm tiwai, git remote add tiwai <url>"  
> things work fine again as it fetched a completely new branch.

Not that adding the remote with "git remote add" will add a fetchspec
line like this:

[remote "tiwai"]
  fetch = +refs/heads/*:+refs/remotes/tiwai/*

where the '+' means to force fetching rewound branches instead of
rejecting them (this is safe, since you are just overwriting tracking
branches, not your local work). So this should not come up again;
presumably your previous remote configuration was set up differently.

-Peff

Re: git pull versus fetch/merge

[Jeff King]

On Mon, Jul 21, 2008 at 07:09:00AM -0400, Jeff King wrote:

> Not that adding the remote with "git remote add" will add a fetchspec
  ^^^

Err, that should be "note", of course. I am having a real problem typing
today.

-Peff

Re: git pull versus fetch/merge

[Rene Herman]

On 21-07-08 13:09, Jeff King wrote:

> On Mon, Jul 21, 2008 at 12:58:10PM +0200, Rene Herman wrote:
> 
>> Thank you. Also due to a reply on the ALSA list by Mark brown I now get  
>> this. Yes, the remote was rebased while I had it setup as a remote here  
>> it seems; only recently have it under this name, so I didn't think that  
>> was the case. After a "git remote rm tiwai, git remote add tiwai <url>"  
>> things work fine again as it fetched a completely new branch.
> 
> Note that adding the remote with "git remote add" will add a fetchspec
> line like this:
> 
> [remote "tiwai"]
>   fetch = +refs/heads/*:+refs/remotes/tiwai/*
> 
> where the '+' means to force fetching rewound branches instead of
> rejecting them (this is safe, since you are just overwriting tracking
> branches, not your local work).

Not here...

rene@7ixe4:~/src/linux/7ixe4$ git remote add tmp 
git://git.alsa-project.org/alsa-kernel.git
rene@7ixe4:~/src/linux/7ixe4$ tail -3 .git/config 

[remote "tmp"]
	url = git://git.alsa-project.org/alsa-kernel.git
	fetch = refs/heads/*:refs/remotes/tmp/*
rene@7ixe4:~/src/linux/7ixe4$ git --version
git version 1.5.5

> So this should not come up again; presumably your previous remote
> configuration was set up differently.

Must be something new or configuration dependent I presume? It's not an 
option to git-remote it seems (but yes, thanks, I guess I'll add the +s 
-- a failed merge is warning enough that I need to rebuild whatever 
branch I'm pulling it into I guess).

Rene.

Re: git pull versus fetch/merge

[Björn Steinbrink]

On 2008.07.21 13:30:12 +0200, Rene Herman wrote:
> On 21-07-08 13:09, Jeff King wrote:
>
>> On Mon, Jul 21, 2008 at 12:58:10PM +0200, Rene Herman wrote:
>>
>>> Thank you. Also due to a reply on the ALSA list by Mark brown I now 
>>> get  this. Yes, the remote was rebased while I had it setup as a 
>>> remote here  it seems; only recently have it under this name, so I 
>>> didn't think that  was the case. After a "git remote rm tiwai, git 
>>> remote add tiwai <url>"  things work fine again as it fetched a 
>>> completely new branch.
>>
>> Note that adding the remote with "git remote add" will add a fetchspec
>> line like this:
>>
>> [remote "tiwai"]
>>   fetch = +refs/heads/*:+refs/remotes/tiwai/*
>>
>> where the '+' means to force fetching rewound branches instead of
>> rejecting them (this is safe, since you are just overwriting tracking
>> branches, not your local work).
>
> Not here...
>
> rene@7ixe4:~/src/linux/7ixe4$ git remote add tmp  
> git://git.alsa-project.org/alsa-kernel.git
> rene@7ixe4:~/src/linux/7ixe4$ tail -3 .git/config 
>
> [remote "tmp"]
> 	url = git://git.alsa-project.org/alsa-kernel.git
> 	fetch = refs/heads/*:refs/remotes/tmp/*
> rene@7ixe4:~/src/linux/7ixe4$ git --version
> git version 1.5.5

Broken in 1.5.5 and 1.5.5.1, Jeff's fix went into 1.5.5.2. Bad luck ;-)

Björn

Re: git pull versus fetch/merge

[Rene Herman]

On 21-07-08 13:33, Björn Steinbrink wrote:

>> rene@7ixe4:~/src/linux/7ixe4$ git --version
>> git version 1.5.5
> 
> Broken in 1.5.5 and 1.5.5.1, Jeff's fix went into 1.5.5.2. Bad luck ;-)

Sheesh. Thanks :-)

Rene.