From: Elijah Newren <email@example.com> To: Denton Liu <firstname.lastname@example.org> Cc: Junio C Hamano <email@example.com>, Viresh Kumar <firstname.lastname@example.org>, Git Mailing List <email@example.com>, firstname.lastname@example.org Subject: Re: [Bug report] git diff stat shows unrelated diff Date: Fri, 15 Feb 2019 11:25:43 -0800 Message-ID: <CABPp-BEmPQb4Q_38S2A_68m+Cu75VDDD2UV0qWBDjL1OUAug9Q@mail.gmail.com> (raw) In-Reply-To: <20190215185202.GA28019@dev-l> On Fri, Feb 15, 2019 at 10:52 AM Denton Liu <email@example.com> wrote: > > On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote: > > Elijah Newren <firstname.lastname@example.org> 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.
next prev parent reply other threads:[~2019-02-15 19:25 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-14 8:22 Viresh Kumar 2019-02-14 18:42 ` Johannes Sixt 2019-02-14 21:23 ` Elijah Newren 2019-02-14 22:10 ` Junio C Hamano 2019-02-15 18:52 ` Denton Liu 2019-02-15 19:25 ` Elijah Newren [this message] 2019-02-15 20:12 ` Junio C Hamano 2019-02-15 22:48 ` Philip Oakley 2019-02-15 23:32 ` Junio C Hamano 2019-02-16 12:47 ` Philip Oakley 2019-02-17 3:34 ` Junio C Hamano 2019-02-17 23:34 ` Philip Oakley 2019-02-18 0:21 ` Junio C Hamano 2019-02-15 19:28 ` Junio C Hamano 2019-02-15 6:40 ` Viresh Kumar 2019-02-15 16:09 ` Elijah Newren 2019-02-18 4:34 ` Viresh Kumar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CABPp-BEmPQb4Q_38S2A_68m+Cu75VDDD2UV0qWBDjL1OUAug9Q@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
email@example.com list mirror (unofficial, one of many) This inbox may be cloned and mirrored by anyone: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 git git/ https://public-inbox.org/git \ firstname.lastname@example.org public-inbox-index git Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ code repositories for the project(s) associated with this inbox: https://80x24.org/mirrors/git.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git