On Mon, Apr 20, 2009 at 01:58:37PM -0700, Junio C Hamano wrote: > > However, especially after I fast-forward my branch tip to M and continue > building on it, it is more useful to treat Dscho's topic as the side > branch that was merged to my mainline that had your patches, for the > purpose of most people. Your "first parent" rule does not match that > expectation. Yes, it does not work here. However, fast-forward merge is not a real merge (though it is often very useful, because it avoids useless commits, yet, it is clearly Git specific thing). Still, what you describe is not very like to happen in practice, because it usually takes some time for any branch to "graduate" to master, and in meanwhile some other branches get merged, so it is not very likely to be fast-forward (and some people always prefer to merge anything to master with --no-ff). > > If we made it easy for Dscho to create the merge M to record my tree as > the first parent, you _could_ make the "first parent" rule to be more > meaningful than it currently is, but without it, it still is merely one of > the heuristics as people suggested in this discussion. Agreed. It is merely a heuristic unless it is not reinforced (like using --no-ff merges to master), but still it is a very good heuristic for most practical purposes, and it even can be improved based on merge messages. Dmitry -- 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