From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sun, 23 Aug 2020 16:03:57 GMT
Subject: Re: git add intent-to-add then git add patch no longer allows edit
Message-ID: <4607f4b5-a5d6-7965-553f-19a52656fb13@gmail.com>
In-Reply-To: <xmqqmu2o9d6j.fsf@gitster.c.googlers.com>

On 21/08/2020 17:27, Junio C Hamano wrote:
> "Raymond E. Pasco" <ray@ameretat.dev> writes:
> 
>> I fixed half of this in a topic that's on master now (it errors out
>> entirely if you try to stage it at all in 2.28.0),
> 
> Yup, thanks for that one.
> 
>> but new file diffs
>> still aren't splittable into hunks. Phillip Wood (on cc) is looking into
>> that; the tricky part is that when split into hunks only the first hunk
>> actually staged can be a "new file" patch.
> 
> Out of a change that adds a file with three parts A, B and C (in
> this order), you could pick the parts A and C, while leaving the
> change to further add B in the middle, and create a patch to add a
> file that has A and C, and apply that to the index alone (i.e. "add
> -p", pick A and C, and "add" that part by applying that "new file"
> diff).  After that, the path is no longer i-t-a but has the real
> contents (i.e. part A followed by part C), so further "add -p" would
> see the difference between the index and the working tree as a
> modification patch.
> 
> So as long as you could come up with a good UI to pick parts from a
> single hunk "new file" diff, "the second and later application must
> be done as modification" should fall out naturally, no?

I think I was talking about edit rather than split. I'd forgotten that 
it used to work with i-t-a additions. I just checked seen and it seems 
to be working again since dscho's patch although the user is presented 
with the full diff header rather than just a hunk header in the editor. 
As you say once the user has staged some part of the diff the rest falls 
out naturally.

Best Wishes

Phillip

(I'm about to go off line for a while)