Re: [PATCH v3] git-add--interactive: manual hunk editing mode

[Jeff King <peff@peff.net>]

On Mon, Jun 09, 2008 at 07:31:51PM +0200, Johan Herland wrote:

> > His work is about fixing up the hunk header as we apply the patch, but a
> > working "e" command in the hunk selection should probably not actually
> > apply, but simply split into two hunks for the loop.
> 
> By "split into two hunks", you mean splitting the original "index -> 
> worktree" hunk (#0) into one hunk that represents "index -> edited" (#1), 
> and another hunk that represents "edited -> worktree" (#2)?

I mean splitting the original "index -> worktree" hunk into two other
hunks, each of which is "index -> worktree" but which can be staged
separately. I.e., what the 's'plit command does, but with finer-grained
control.

But I think that is what you are trying to say...

> From a technical POV this might make sense, but AFAICS, users would always 
> want to answer 'y' to #1, and 'n' to #2 (see [1]), so from a user POV, 
> git-add--interactive should simply stage #1, and drop #2.

Yes. I assumed we wanted to maintain the separate splitting operation,
since that parallels the existing split (so the interface is consistent)
and it logically separates the two parts (you split, and then you choose
the part you want).

But honestly, I don't really see a use case that isn't covered by
"manually edit the diff and apply the hunk". And the rationale in your
"side note" indicates that you think the same way.

So now I wonder if we _can_ leverage Dscho's work here. I.e., can we
simply send the edited hunk to "git apply --recount --cached" (instead
of doing a "git apply --check")?

The main problem I see at this point is that it screws up the line
numbering for _every other hunk_, so later hunks in that file might not
apply (IIRC, we usually save up all of the "yes" hunks and apply at the
end). So it might be needed to do a --recount --check, and then actually
apply at the end.

I'll try to play around with that.

-Peff