Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Junio C Hamano wrote: >> That world view is broken, isn't it? Perhaps you forgot to consider >> symmetric differences, where left positives and right positives have >> to be treated differently. > > No, I did consider symmetric difference. How is git log A B --not > $(git merge-base --all A B) different from git log B A --not $(git > merge-base --all A B)? Compare these (gitk will give you nicer picture): $ git log --oneline --graph --left-right A...B $ git log --oneline --graph --left-right B...A > Um, my point was again that "ordering does not matter"; therefore for > a third type of commit, you need a command-line parameter. > >> git show A..B C..D > > This is seriously bad. We'll have to think about fixing this along the way. For the purpose of "doing one thing and well", we have drawn the line at "we operate on at most one DAG and specify what happens to it with various other parameters, which may include commits" long time ago. If you want to operate on more than one DAG, the cleanest way is to do the set computation for A..B and C..D separately and combine them yourself (which is the example you omitted from the quote). The setup_revisions() machinery that is the foundation of the current codebase has this design decision ingrained in it. That is where the marking of commits with only two primary colors (i.e. the UNINTERESTING bit) comes from, and where the "single DAG" limitation originates. You can extending it a little bit (e.g. by introducing a secondary color left/right) to enrich it, but fundamentally the infrastructure pretty much assumes we operate on one DAG and a commit is either outside or inside (or at the boundary) of it. It may be nice if the low-level operated on more than one DAG, but it is very close to a proposition to throw the baby with the bathwater and restart from scratch. It is a lot more than a little "as an aside" task. -- 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