On 02/05/2013 23:05, Junio C Hamano wrote: > >>> ....Z...A===X---o---o---B >>> \\ / >>> W---Y >>> > OK, I think I understand it, and we are in agreement. For the > purpose of the above paragraph, a side branch is what is not on the > "--ancestry-path", so all of the below "examples" are about the > behaviour when --ancestry-path is used. Ah, in fact, no. In some previous mails I was concentrating on ancestry-path, but those 3 examples were really of ordinary "A..B", with W+Y in the INTERESTING set. I think the side-branch logic remains sound and desirable even in the absence of --ancestry-path, so I don't think this is an ancestry-path change. (And from a basic naive usability point of view I'm much more interested in improving the more obvious modes than the rather more obscure --ancestry-path.) Ancestry path forces side branches to be ignored - it's the "simple" case for ignoring (and understanding) side branches. But if we let other modes know where the bottom is, they too can benefit from reliable side branch logic - we can find out if anything happened on side branches, but we can also ignore them completely if they turn out to be totally irrelevant. When not using ancestry-path, the side branches this patch works on are thosewhich go off and don't come back - they stub off at some UNINTERESTING commit other than the bottom(s). If no other limiting is set, they must have hit an ancestor of our BOTTOM commit(s); simplify-merges could have potentially pruned away if unlimited. And this patch restores that pruning ability - simplify-merges can rewrite them back to just 1 UNINTERESTING merge parent at the boundary (looking like an ancestry-path boundary), then this patch can chuck the boundary merge. Hey presto, irrelevant branch now invisible. And the patch also provides benefits to all other modes. I'll post v3 of the sequence tomorrow - it includes a new test which illustrates the changes - it's a 60-or-so-item test set, with about 15 "failures" in a variety of modes that get fixed by this sequence. I think that should make an excellent discussion topic. We'll see whether folks agree with my view about what should and shouldn't be shown... Kevin -- 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