Denton Liu <liu.denton@xxxxxxxxx> writes: > On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote: > >> 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 doubt that such a change helps anybody more than it hurts. Defining A..B to mean something totally different based on a hidden config will hurt those who want to help others. It would even hurt those who are new to Git and blindly set such configuration because their local guru tells them to and then goes on to read code snippets and docs on the web outside our control that have been written with the established meaning of what A..B and A...B mean to "git diff". There is nothing sensible in using dots, i.e. range notation, between A and B _if_ you are trying to compare A and B, i.e. two endpoints. Just use "diff A B" and you are OK.
