Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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. [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. -- 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