On Fri, Feb 15, 2019 at 10:52 AM Denton Liu <liu.denton@xxxxxxxxx> wrote: > > On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > > > > The only thing I seem to be able to retain is the following: "git > > > diff D..E is totally useless and should be an error because (1) it > > > doesn't do what I expect and (2) for folks that want the behavior > > > currently gotten with that syntax can instead just use a space instead > > > of a double dot." > > > > That sums up pretty nicely. diff is fundamentally an operation > > between two endpoints, so the range notation a..b does not work > > nicely with it at the conceptual level. > > > > When we realized that we can take advantage of the above fact, and > > reuse a range notation to mean something that is generally useful in > > the context of diff, such as 'one end of the comparison is the merge > > base between a and b, and the other end is b', it was too late to > > use "a..b", as an early adopters of Git was already used to the fact > > that "a..b" happened to mean the same thing as "comparison of one > > end is a, the other end is b", pretty much implemented without much > > thought. > > > > It might be _possible_ to spend a year (i.e. 4 cycles) to start > > warning when two-dot notation is used for "git diff" (only, not any > > plumbing like "git diff-files") and tell the user to use the more > > logical two-end notation "git diff A B" and then eventually error > > out when two-dot notation is used, while retaining the three-dot > > notation throughout and to the eternity. I am not sure if it is > > worth the deprecation cost, though. > > > Instead of outright deprecating it, would it make sense to include a > configuration option, say "diff.sensibleDots", that would enable a user > to set the dots to the other form if they desire? I think Junio's suggested steps would still have to come first, and there may also need to be a time period after two-dot notation is an error before we were to try to repurpose it for something else (e.g. to make it behave the same as triple-dot). Adding a config to change things now without both a deprecation and error period would invite horrible surprises and bug reports; people need time and warning to change workflows and fix existing scripts that might be out there. > This has bugged me for long enough that if there's a desire for this > from others, I'm willing take on the effort of making this change. I was going to put the deprecation and erroring steps on my (always growing) TODO list to eventually get to it, but if you're motivated, go for it; I wouldn't get to it soon anyway.
