From: Junio C Hamano <email@example.com> To: Elijah Newren <firstname.lastname@example.org> Cc: Denton Liu <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 12:12:41 -0800 Message-ID: <email@example.com> (raw) In-Reply-To: <CABPp-BEmPQb4Q_38S2A_68m+Cu75VDDD2UV0qWBDjL1OUAug9Q@mail.gmail.com> Elijah Newren <firstname.lastname@example.org> writes: >> 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. Historically, it was a mistake to allow A..B to be used for two endpoints, which was made back when we haven't thought things through. That is why I stopped "warn to deprecate and then completely remove", as I do not think it would help people very much if "git diff A B" can be spelled with two-dots. But in a distant future long after that happens, by the time nobody remembers what A..B meant for "git diff", I do not think I'd strongly be opposed to reusing it to mean something different.
next prev parent reply index 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 2019-02-15 20:12 ` Junio C Hamano [this message] 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 publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
firstname.lastname@example.org list mirror (unofficial, one of many) Archives are clonable: 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 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.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox