Ramkumar Ramachandra <artag...@gmail.com> 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

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to