Message ID | 20080909100628.GA15298@oksana.dev.rtsoft.ru (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
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. (3) Even more importantly, even if you notice there is some difference, you cannot produce the postimage by only looking at the hash (this is obvious -- otherwise by definition you broke SHA-1), so you cannot tell *how* the patch was modified. What is of much more practical value to learn here in the context of this topic would be that after accepting such a patch that does not use -M (so that non-git people can use patch(1) to apply), a git person can still verify the result with "git show -M" to see what changes other than a pure rename was made by the patch.
On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote: > 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 <avorontsov@ru.mvista.com> writes: > On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote: > ... >> ... 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... a. Why not? Even if your patch is (totally uninteresting) pure rename, it is natural to review the patch before you send out, and it also is natural to get tempted to fix typoes, just for a straight normal patch. b. If you can expect good behaviour out of people, by declaring "Not for rename patches" as your guarantee, what's the point of this discussion? > 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? Implementation is easy (I said "would be fun to code", didn't I? --- by the way, how did you match "index_deleted_file" with "index_new_file"?). My point was that it would not be reliable enough to be useful in practice.
diff --git a/file b/file deleted file mode 100644 index 257cc56..0000000 --- a/file +++ /dev/null @@ -1 +0,0 @@ -foo diff --git a/file_renamed b/file_renamed new file mode 100644 index 0000000..257cc56 --- /dev/null +++ b/file_renamed @@ -0,0 +1 @@ +bar