Re: git apply vs. renamed files index mismatch
On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote:
Show 20 quoted lines
> Anton Vorontsov <avorontsov@ru.mvista.com> writes:
>
> > Now consider the following patch (modified by hand: it should say
> > +foo, but I changed it to +bar).
> > ...
> > The "index ..." stuff says that there are no changes and it is
> > pure rename, but obviously there is a change.
>
> Ah, I see what you mean. But in general, it is not obvious at all.
>
> If you have the identical preimage (recorded on the LHS of the index line)
> or the patch reproduces the postimage in full (i.e. "create a new file"),
> you *could* notice. It's an interesting idea from git person's point of
> view (i.e. "would be fun to implement"), but I doubt it would be useful in
> practice, because:
>
> (1) You often do not have the identically matching preimage;
>
> (2) More importantly, it is not unusual for people to *edit* the patch in
> their MUA (think of typofixes), after getting it out of git.
Not for rename patches...
> (3) Even more importantly, even if you notice there is some difference,
Just noticing that there is a difference is enough.
As for implementing, isn't this as simple as this pseudo code:
if (index_deleted_file == index_new_file)
if (deleted_file != new_file)
printk("warning\n");In the git-apply?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2