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. -- 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