On 21/08/2020 17:27, Junio C Hamano wrote:
"Raymond E. Pasco" <ray@xxxxxxxxxxxx> 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)
