Re: Itches with the current rev spec

Ramkumar Ramachandra [off-list ref] writes:

Junio C Hamano wrote:

quoted

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.

quoted

    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.

Junio C Hamano wrote:

Compare these (gitk will give you nicer picture):

   $ git log --oneline --graph --left-right A...B
   $ git log --oneline --graph --left-right B...A

Darn.  I didn't realize that rev-list had a --left-right to mark
commits with <, >, or - before giving it to the command.  So, that's
one more thing to note: there are positive and negative commits, as
well as commits marked with a direction (in the special case of
--left-right).  Have we missed anything?

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.

I know too little to comment on the issue.  I was merely musing.