On Wed, Mar 21, 2007 at 08:37:07AM -0700, Junio C Hamano wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html