From: Phillip Wood <phillip.wood123@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Raymond E. Pasco" <ray@ameretat.dev>,
phillip.wood@dunelm.org.uk, Thomas Sullivan <tom@msbit.com.au>,
git@vger.kernel.org
Subject: Re: git add intent-to-add then git add patch no longer allows edit
Date: Mon, 7 Sep 2020 19:00:13 +0100 [thread overview]
Message-ID: <a8099cb4-97e0-5596-72a1-10402762015b@gmail.com> (raw)
In-Reply-To: <xmqqd02y7rwj.fsf@gitster.c.googlers.com>
On 06/09/2020 18:10, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Thanks for reminding me, I did not really think about it anymore. The
>> built-in `git add -i`/`git add -p` has been available since v2.25.0. Since
>> v2.26.0, we also respect that flag in the `-p` modes of `checkout`,
>> `stash`, etc
>
> That is 9a5315ed (Merge branch 'js/patch-mode-in-others-in-c', 2020-02-05)
>
>> And from the way at least _I_ read the commit log, it seems that the code
>> has been pretty stable (except for that bug fix where `e` was allowed by
>> mistake).
>
> As long as it has been widely used, that is.
Exactly, I'm not sure it has been that widely used yet. (I'm
interested in this area and only got round to using the C version a
couple of weeks ago so I wonder how many others have)
> I do not think we
> deeply mind a bug like the `e` one that does not affect the utility
> or the correctness of the command that much.
The bug with editing in this thread is also fairly minor I think. I
suspect the main area for serious bugs is hunk splitting and
joining.
> If we do not flip the
> "use the built-in variant" for those with feature.experimental we
> really should do so to widen the canarying population immediately.
That's a good idea
Best Wishes
Phillip
next prev parent reply other threads:[~2020-09-07 18:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 4:27 git add intent-to-add then git add patch no longer allows edit Thomas Sullivan
2020-08-21 5:25 ` Raymond E. Pasco
2020-08-21 16:27 ` Junio C Hamano
2020-08-23 16:03 ` Phillip Wood
2020-08-24 16:23 ` Raymond E. Pasco
2020-08-24 17:28 ` Phillip Wood
2020-08-24 21:03 ` Raymond E. Pasco
2020-09-04 10:05 ` Phillip Wood
2020-09-04 6:56 ` Johannes Schindelin
2020-09-06 17:10 ` Junio C Hamano
2020-09-07 18:00 ` Phillip Wood [this message]
2020-09-08 16:05 ` Junio C Hamano
2020-09-08 19:52 ` Johannes Schindelin
2020-09-08 22:00 ` Junio C Hamano
2020-09-09 9:40 ` Phillip Wood
2020-09-05 18:36 ` Raymond E. Pasco
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=a8099cb4-97e0-5596-72a1-10402762015b@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ray@ameretat.dev \
--cc=tom@msbit.com.au \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).