Jeff King <peff@xxxxxxxx> writes:
> On Tue, Dec 08, 2009 at 12:47:24AM -0500, Jeff King wrote:
>
>> There is a slightly different approach we could take, too: keep the
>> "deletion" hunk as a first-class hunk, and just meld the content hunk's
>> output into it. Then both cases would get the "Stage deletion" question
>> instead of the "Stage this hunk" you get now for non-empty files (which
>> just happens to trigger a deletion due to the headers).
>
> BTW, the code for this is the much smaller change below. If you prefer
> that, I can squash in the test and write up an appropriate commit
> message.
Doubly interesting, as I recall reading "That would take some refactoring,
though, as pulling the deletion hunk"
... goes and looks ...
Ah, Ok, the "refactoring" refers to the "header reordering weirdness".
That might be something we may want to fix someday, when we find ourselves
needing to add a feature to turn deletion into non-deletion or vice versa
during "add -p" [e]dit, as I suspect that the "hunk editing" codepath does
not keep track of what the user's patch is doing, to the point that it
does not even know how many lines there are supposed to be in the
resulting hunk that it asks "git apply" to recount. There is no way to
add/delete "deleted file" line if the logic does not know what the patch
is doing.
But someday is not today. I think this six-liner is preferable.
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 35f4ef1..02e97b9 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -1217,7 +1217,11 @@ sub patch_update_file {
> if (@{$mode->{TEXT}}) {
> unshift @hunk, $mode;
> }
> - if (@{$deletion->{TEXT}} && !@hunk) {
> + if (@{$deletion->{TEXT}}) {
> + foreach my $hunk (@hunk) {
> + push @{$deletion->{TEXT}}, @{$hunk->{TEXT}};
> + push @{$deletion->{DISPLAY}}, @{$hunk->{DISPLAY}};
> + }
> @hunk = ($deletion);
> }
>
--
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