Re: [PATCH] git apply: do not match beginning in special unidiff-zero case

[Junio C Hamano <gitster@pobox.com>]

Clemens Buchacher <drizzd@aon.at> writes:

> If a unidiff patch without any context modifies the second line, it does
> not match the beginning, even though oldpos == 1.

Heh, it seems we independently reached the same patch, so I'll squash in
your new test.

Having did all this, I have to warn you, git-gui, and anybody who is
tempted to use --unidiff-zero in "add -i [e]dit" that the -U0 format is
inherently unreliable _unless the patch you are feeding is perfect_.

By reducing the context, especially when you have only addition without
deletion next to it (iow, "modification to an existing line"), the only
information as to where that line needs to be inserted that you are
telling "apply" is the postimage offset, so you have to be absolutely sure
that the hunk header "@@ -K,L +M,N @@" you are feeding has the correct
value for "M".

For git-gui's "pick and apply", you should be able to, but once you start
allowing random manual editing of hunks, by definition the patch is _not_
perfect ("add -i [e]dit" even admits that it does not know what it is
doing by passing --recount to "apply").

So try to avoid --unidiff-zero.  git-gui should have _enough_ information
to add surrounding context back to the lines the user picked from the UI,
and I do not see a reason other than sheer lazyness for it to be using the
option.