Re: [BUG] Highly inconsistent diff UI

Ramkumar Ramachandra [off-list ref] writes:

Junio C Hamano wrote:

quoted

Wait.  What does "lists H G D A..C" even mean?  H, G and D I would
understand, but how does "log" ever "list" A..C???

Now you really confused me.

What you said was technically correct.  I was pointing out that the
graph was misleading because it didn't show any commits between A and
B/C.  A is ofcourse UNINTERESTING.

quoted

What does it mean "log" "In reality" shows A..B?  Didn't you just
say it either lists "H G D C" or "H G D B"?  Neither B nor C is what
you did since you forked?  Now, what did you do since you folked
(which is the question you are asking)?  You made commit D,
back-merged from upstream to record G, and then made another commit
H.  That "H G D", which is what you get from "log F..H", isn't it??

Okay, so the question is ill-formed.  The technically correct version
is "which commits are reachable from my branch since I forked off?",
but I don't know if anyone will want to ask that question.

OK, I missed what you wanted to say with A..C, which only had B in
the concrete depiction.  Omitting all other merge bases and picking
only one (say C) at random will include not just B but all the other
commits that are not what you did since you forked before C.  Which
I think makes the example even less interesting, and you seem to
agree to that.

Thanks for clarification.  I was really getting worried if I was
missing something fundamental in what you were saying.

I'm trying to look for one more command that will find A~B useful, so
we can remove the A...B wart from diff; inventing it just to replace
the wart isn't reason enough.  Do you disagree with the approach?

Have you ever seen me saying "it sounds like a good idea" to a
solution that is looking for a problem? ;-)

"diff A...B" works already, and stopping to refer to "diff A..B"
(the documentation patch you sent out) hopefully will make it less
confusing.  I do not see a huge upside in replacing it with yet
another notation people need to learn (and possibly make them
unlearn a working notation). The downside of it feels far worse.

What are your thoughts on overloading it for rebase?  git rebase
master~ to rebase onto the merge-base of master and HEAD?

Not very interested [*0*], but I haven't thought things through.

In order to express only what we can currently express (i.e. not
extending for a DAG with a single bottom and multiple refs at tops),
I think it is sufficient to allow "rebase [--onto=$there] origin.."
[*1*]; we can infer what ref is being rebased from the range we get
from the command line by asking rev_cmdline, and it may be more
natural to people who grew up with "git log origin..".

That approach would express the DAG with the usual revision range
specifier on the command line, limited to those range notations that
have a single bottom and a single top.  That range defines the DAG
that will be replayed, and its single top defines what ref is
updated as the result.

When --onto is not specified, we could choose to use two- vs three-
dot notations to select what "onto" to use by default [*2*].  For
example, "rebase origin.." could be a way to replay your work on top
of their work you fetched, while "rebase -i origin..." could be a
way to identify your work since you forked from them, and tweak then
without changing the base, i.e. the fork point (the latter of which
would match what you would get from "diff A...B" naturally).

If we later want to add "a DAG with a single bottom and multiple
refs at tops", it could be spelled as "rebase --multi --onto=$there
^origin rr/rebase-doc rr/triangle" or something [*3*].

But footnote *2* turns out to be the most important point in this
message. Earlier I said I haven't thought things through, but I
think I have now.


[Footnote]

*0* "git rebase master~" would rebase your current history on top of
one commit before master, but you could choose to use some line
noise character other than tilde.

*1* This is similar to the way we taught "origin.." and "-3 HEAD" to
"format-patch" that originally only took "origin".

*2* Having said that, I do not particularly like the approach to
exploit the difference between two- and three-dot forms and use it
in choosing which commit to use as the default "onto".

It might be more useful to have the distinction between "rebase -i"
and "rebase" make that decision. 

Replaying on top of the merge base would not be useful unless we are
doing "rebase -i" (it would be a no-op by definition). From that
point of view, "rebase origin" (or "rebase origin.." or "rebase
origin..."), because it is replaying your work on top of others, may
use --onto=origin by default. On the other hand, "rebase -i origin"
(or "rebase -i origin.." or "rebase -i origin..."), because you use
the command in order to tweak your work, and you mention 'origin'
merely to let Git know where your fork point is, may replay on the
original fork point it discovers with merge-base.

Or something like that.  The above makes me think that focusing on
the revision range notation is not terribly productive when
exploring how to make "rebase" easier to use to end users.

*3* "--multi" is merely an example to make it easy to tell the
command line from the traditional form that has an extra "switch to
this branch before starting anything" argument.

Junio C Hamano wrote:

Have you ever seen me saying "it sounds like a good idea" to a
solution that is looking for a problem? ;-)

I'll try to avoid that approach in the future.

"diff A...B" works already, and stopping to refer to "diff A..B"
(the documentation patch you sent out) hopefully will make it less
confusing.  I do not see a huge upside in replacing it with yet
another notation people need to learn (and possibly make them
unlearn a working notation). The downside of it feels far worse.

So, my question is about whether A..B is really that confusing.  We
might exploit the differences between .. and ... in all the commands,
and document it properly.  We just have to stop calling .. and ...
canonical "range" commands.  We can stick to overriding these two for
now.

What does consistency even mean?  What does it mean for rebase A..B to
have logical similarity to log A..B?  If this similarity cannot be
precisely defined, consistency is just an illusion.

Not very interested [*0*], but I haven't thought things through.

Yeah, neither have I.  I'm asking for input.

In order to express only what we can currently express (i.e. not
extending for a DAG with a single bottom and multiple refs at tops),
I think it is sufficient to allow "rebase [--onto=$there] origin.."
[*1*]; we can infer what ref is being rebased from the range we get
from the command line by asking rev_cmdline, and it may be more
natural to people who grew up with "git log origin..".

That's fine.  The tricky part is: what is it rebased onto?  origin?

That approach would express the DAG with the usual revision range
specifier on the command line, limited to those range notations that
have a single bottom and a single top.  That range defines the DAG
that will be replayed, and its single top defines what ref is
updated as the result.

Okay.

When --onto is not specified, we could choose to use two- vs three-
dot notations to select what "onto" to use by default [*2*].  For
example, "rebase origin.." could be a way to replay your work on top
of their work you fetched, while "rebase -i origin..." could be a
way to identify your work since you forked from them, and tweak then
without changing the base, i.e. the fork point (the latter of which
would match what you would get from "diff A...B" naturally).

If we later want to add "a DAG with a single bottom and multiple
refs at tops", it could be spelled as "rebase --multi --onto=$there
^origin rr/rebase-doc rr/triangle" or something [*3*].

I'm an idiot.  What I was bouting as consistency was artificial
constraints _I_ imposed on the rev spec.  Why shouldn't the command
behave differently for:

1. One positive and one negative.
2. Multiple positives and one negative.
2.1 When there are two positives, and --multi isn't on.
2.2 When --multi is on.

What is it violating?

The UI you have proposed is very compelling, although I'm surprised
you did it top-down.

[Footnote]

*0* "git rebase master~" would rebase your current history on top of
one commit before master, but you could choose to use some line
noise character other than tilde.

Not urgent.

*1* This is similar to the way we taught "origin.." and "-3 HEAD" to
"format-patch" that originally only took "origin".

Okay.

*2* Having said that, I do not particularly like the approach to
exploit the difference between two- and three-dot forms and use it
in choosing which commit to use as the default "onto".

It might be more useful to have the distinction between "rebase -i"
and "rebase" make that decision.

Replaying on top of the merge base would not be useful unless we are
doing "rebase -i" (it would be a no-op by definition). From that
point of view, "rebase origin" (or "rebase origin.." or "rebase
origin..."), because it is replaying your work on top of others, may
use --onto=origin by default. On the other hand, "rebase -i origin"
(or "rebase -i origin.." or "rebase -i origin..."), because you use
the command in order to tweak your work, and you mention 'origin'
merely to let Git know where your fork point is, may replay on the
original fork point it discovers with merge-base.

I'll have to think about this.

Or something like that.  The above makes me think that focusing on
the revision range notation is not terribly productive when
exploring how to make "rebase" easier to use to end users.

You managed a top-down version quite quickly, while I was stuck at
consistency :)

*3* "--multi" is merely an example to make it easy to tell the
command line from the traditional form that has an extra "switch to
this branch before starting anything" argument.

Cute way of putting it.