Hi,
On Tue, 14 Apr 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> > On Sun, 12 Apr 2009, Junio C Hamano wrote:
> >
> >> * js/add-edit (Wed Apr 8 23:30:24 2009 +0200) 1 commit
> >> - git-add: introduce --edit (to edit the diff vs. the index)
> >>
> >> I am Ok with the general idea, but the error detection needs to be
> >> more robust than merely relying on --recount.
> >
> > You mean something like saving an extra copy of the patch, and
> > checking if common or removed lines were either removed or kept
> > intact?
>
> No, editing a removed line and changing it to an unchanged line is
> perfectly fine.
>
> I was thinking more about people touching the lines near the hunk
> boundary (e.g. insert a new line at the beginning of the hunk) which
> would not be compatible without --unidiff-zero hack while applying, and
> --unidiff-zero hack should not be used if we care about the correctness.
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).
Do you agree?
Ciao,
Dscho
--
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