On Wed, Mar 21, 2007 at 08:37:07AM -0700, Junio C Hamano wrote:

quoted text
> I often hear from people who seems to like "fetch & merge",
> instead of "pull & reset ORIG_HEAD", as a workflow to avoid
> undesirable merging.  This might largely be a matter of taste,
> but from philosophical point of view, fetch & merge is a sign of
> distrust (your default is not to merge, and you merge only when
> you choose to), and pull & reset is the opposite (your default
> is to merge, and after you inspect you may choose not to merge).
> Tool support to encourage the former feels somewhat wrong.

I don't think it necessarily means distrust; I always do a fetch +
inspect + merge, and I am often fetching my own code to a different
platform!

My reason is that the inspect step takes an arbitrary amount of time,
and I don't want to lose my place. That is, I might go eat dinner in the
middle of the 'inspect' and then come back. By using my branch head as a
checkpoint, I am recording "I have inspected up to my master"; when I am
done inspecting, the merge moves my checkpoint forward. That way I never
fail to look over the commits; I don't do this out of distrust, but
because I want to see all of the commits.

I could just use FETCH_HEAD, but it is easy to overwrite accidentally
(if I do another git-fetch after dinner, not realizing I'm in the middle
of an inspection already, or if I'm looking to grab more changes). I
could also use the reflog, but it will also change if I fetch again in
the middle.

Of course, I use this for small-ish projects like git, or personal
projects. I don't think trying to glance over every commit to the kernel
would be scalable.

-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html