Junio C Hamano <junkio@xxxxxxx> writes:
> ... these may or may not be at the end of the file, so
> inspecting what blank lines they have at the end is not
> sufficient. If "new" does not introduce new blank lines at its
> end, then you can be sure that you are not adding trailing blank
> lines, but even if "new" does introduce a new blank line at the
> end, you do not know if that is adding it to the end of the
> file, or in the middle.
>
> You do not know where the hunk is applied until you do the loop
> that follows the part your patch we are discussing.
If I were doing this, I would probably do it this way:
(1) Inside apply_one_fragment(), where "case '+':" appears, count
the blank (not just '\n', but matches /^\s*$/) lines at the
end of "new" side. As soon as you fall into "case ' ':" or
"case '-':" or non-blank line in "case '+':", you reset the
counter to zero, so that what you are counting is the
number of blank lines that would have get added, if the
hunk were to be applied at the end of the file. Keep that
number ofter you separated the fragment into new and old.
(2) In the same function, inside the big "for (;;)" loop that
figures out where to apply that "old" => "new" change, use
the number you gathered in the step (1) to trim what is
applied, where the real application happens, which is the
part that has memmove()/memcpy(), only when you know you
are applying the hunk at the end of the file. That is the
only place in the function that knows where the hunk is
being applied.
-
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
