Re: add -e, was Re: What's cooking in git.git (Apr 2009, #02; Sun, 12)

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: add -e, was Re: What's cooking in git.git (Apr 2009, #02; Sun, 12)

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:46:36

Johannes Schindelin [off-list ref] writes:
Actually, I am beginning to hate the idea of having this in add -e, but 
would prefer it to be in apply ("git apply $PATCH" could -- and should -- 
complain when not being called with --unidiff-zero and encountering a 
patch that should (but does not) have common context lines).
I think it already complains by rejecting.  The thing is, only "add -e"
knows that the patch being fed to apply is potentially manually corrupt by
the end user.

Re: add -e, was Re: What's cooking in git.git (Apr 2009, #02; Sun, 12)

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:46:36

Hi,

On Tue, 14 Apr 2009, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Actually, I am beginning to hate the idea of having this in add -e, 
but would prefer it to be in apply ("git apply $PATCH" could -- and 
should -- complain when not being called with --unidiff-zero and 
encountering a patch that should (but does not) have common context 
lines).
I think it already complains by rejecting.  The thing is, only "add -e" 
knows that the patch being fed to apply is potentially manually corrupt 
by the end user.
I think that this extra-check for missing context lines is a substantial 
amount of work for little use, as the most common mistakes are other 
things, and _they_ will be hard to catch, as I illustrated.

So, how about adding a warning before the beginning of the patch instead?

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help