From: Junio C Hamano <firstname.lastname@example.org> To: Philip Oakley <email@example.com> Cc: Elijah Newren <firstname.lastname@example.org>, 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: Sun, 17 Feb 2019 16:21:55 -0800 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> (Philip Oakley's message of "Sun, 17 Feb 2019 23:34:53 +0000") Philip Oakley <email@example.com> writes: > It was my understanding that the end point would be total removal of > any options and the typing of the double dot would be an error. Given > that hard end point I was looking to ensure that users of double dots > have a manageable route to unlearning old bad habits. Thus the first > phase would be opt-in, Sorry, but I do not see any logical connection in this "Thus". If we are still undecided if deprecating double-dot is a good idea and trying to gauge the impact, then perhaps an early "opt-in" to leave the door open for aborting the transition plan might make sense (as an escape hatch for _us_ the project developers to make excuse to the end users). But I am getting an impression that it is not the plan you have in mind. > To train the fingers, and to check local scripts and aliases, the user > needs feedback, preferably at a time of their convenience (as opposed > to being a time of inconvenience), so assuming they have been paying > moderate attention to the release notes, providing the opt-in phase > gives them that. And to those who haven't been paying attention, what happens when your "first phase" period expires? I would be a lot more sympathetic if your argument were "some people will not be ready to start training, and they will be helped if we had an opt-out knob early in the long deprecation period". Even those who have not been paying attention at all _will_ be hit by deprecation warning, and that is when they can decide if they want to start training or they are not ready and want to postpone, so in that sense, "initial opt-out" may make sense, but I do not see how "initial opt-in" can be a viable thing.
next prev parent reply other threads:[~2019-02-18 0:22 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 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 [this message] 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 \ --firstname.lastname@example.org \ --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) 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 \ email@example.com 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