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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
