Ramkumar Ramachandra <artag...@gmail.com> writes:
> Junio C Hamano wrote:
>> 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.
>> 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.
*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.
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