From: Rene Herman <rene.herman@keyaccess.nl>
To: "Björn Steinbrink" <B.Steinbrink@gmx.de>
Cc: git@vger.kernel.org, Takashi Iwai <tiwai@suse.de>
Subject: Re: git pull versus fetch/merge
Date: Mon, 21 Jul 2008 12:58:10 +0200 [thread overview]
Message-ID: <48846BC2.4090407@keyaccess.nl> (raw)
In-Reply-To: <20080721102320.GA19776@atjola.homenet>
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.
next prev parent reply other threads:[~2008-07-21 10:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-21 9:11 git pull versus fetch/merge Rene Herman
2008-07-21 10:23 ` Björn Steinbrink
2008-07-21 10:58 ` Rene Herman [this message]
2008-07-21 11:09 ` Jeff King
2008-07-21 11:09 ` Jeff King
2008-07-21 11:30 ` Rene Herman
2008-07-21 11:33 ` Björn Steinbrink
2008-07-21 11:39 ` Rene Herman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48846BC2.4090407@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=B.Steinbrink@gmx.de \
--cc=git@vger.kernel.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).