Re: git pull versus fetch/merge
- From
- Rene Herman <rene.herman@keyaccess.nl>
- Date
- Jul 21, 2008, 10:58 UTC
- Message-ID
- <48846BC2.4090407@keyaccess.nl>
- In-Reply-To
- <20080721102320.GA19776@atjola.homenet>
On 21-07-08 12:23, Björn Steinbrink wrote:
Show 10 quoted lines
> 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.