{"thread":{"id":"15437","subject":"git apply vs. renamed files index mismatch (was: Re: [PATCH 1/4] POWERPC: Rename dma_64.c to dma.c)","startedAt":"2008-09-08T21:27:17Z","lastAt":"2008-09-10T03:31:01Z","messageCount":11,"participants":["Anton Vorontsov","Scott Wood","Christoph Hellwig","Junio C Hamano","Geert Uytterhoeven"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"90136","messageId":"20080908212717.GA21338@oksana.dev.rtsoft.ru","threadId":"15437","inReplyTo":"48C57A92.6060608@freescale.com","subject":"git apply vs. renamed files index mismatch (was: Re: [PATCH 1/4] POWERPC: Rename dma_64.c to dma.c)","fromName":"Anton Vorontsov","fromEmail":"avorontsov@ru.mvista.com","sentAt":"2008-09-08T21:27:17Z","receivedAt":"2008-09-08T21:27:17Z","isPatch":true,"sender":{"key":"avorontsov@ru.mvista.com","avatar":null},"body":"On Mon, Sep 08, 2008 at 02:18:42PM -0500, Scott Wood wrote:\n> Becky Bruce wrote:\n>> This is in preparation for the merge of the 32 and 64-bit\n>> dma code in arch/powerpc.\n>>\n>> Signed-off-by: Becky Bruce \n>> ---\n>> arch/powerpc/kernel/Makefile | 2 +-\n>> arch/powerpc/kernel/dma.c | 200 ++++++++++++++++++++++++++++++++++++++++++\n>> arch/powerpc/kernel/dma_64.c | 200 ------------------------------------------\n>> 3 files changed, 201 insertions(+), 201 deletions(-)\n>> create mode 100644 arch/powerpc/kernel/dma.c\n>> delete mode 100644 arch/powerpc/kernel/dma_64.c\n>\n> Passing -M to git format-patch makes it much easier\n\nI always thought that posting \"-M\" patches to the public lists is\ndiscouraged since it is quite difficult to apply them via patch(1).\nAlso think of non-git users...\n\n> to see whether \n> anything changed between the old file and the new file.\n\nThis is still possible by comparing the hashes:\n\ndiff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c\nnew file mode 100644\nindex 0000000..ae5708e\n[...]\ndiff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c\ndeleted file mode 100644\nindex ae5708e..0000000\n\nThat is, if hashes match then it was pure rename.\n\nThough, too bad git {apply,am} does not produce any warnings if there\nare any hidden changes...\n\nCc'ing git mailing list.\n\n-- \nAnton Vorontsov\nemail: cbouatmailru@gmail.com\nirc://irc.freenode.net/bd2\n"},{"id":"90138","messageId":"48C59B71.3040902@freescale.com","threadId":"15437","inReplyTo":"20080908212717.GA21338@oksana.dev.rtsoft.ru","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Scott Wood","fromEmail":"scottwood@freescale.com","sentAt":"2008-09-08T21:38:57Z","receivedAt":"2008-09-08T21:38:57Z","isPatch":false,"sender":{"key":"scottwood@freescale.com","avatar":null},"body":"Anton Vorontsov wrote:\n> I always thought that posting \"-M\" patches to the public lists is\n> discouraged since it is quite difficult to apply them via patch(1).\n> Also think of non-git users...\n\nI think the substantially enhanced reviewability trumps non-git-users \nwho can follow the rename instructions manually (or fix up their patch \nutility) if they insist on shunning tools that would make their life easier.\n\n> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c\n> new file mode 100644\n> index 0000000..ae5708e\n> [...]\n> diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c\n> deleted file mode 100644\n> index ae5708e..0000000\n> \n> That is, if hashes match then it was pure rename.\n\nI suppose, though it's not as easy to spot, and won't help in showing \nwhat the differences are if there are any.\n\n-Scott\n"},{"id":"90139","messageId":"20080908215441.GA924@oksana.dev.rtsoft.ru","threadId":"15437","inReplyTo":"48C59B71.3040902@freescale.com","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Anton Vorontsov","fromEmail":"avorontsov@ru.mvista.com","sentAt":"2008-09-08T21:54:41Z","receivedAt":"2008-09-08T21:54:41Z","isPatch":false,"sender":{"key":"avorontsov@ru.mvista.com","avatar":null},"body":"On Mon, Sep 08, 2008 at 04:38:57PM -0500, Scott Wood wrote:\n> Anton Vorontsov wrote:\n>> I always thought that posting \"-M\" patches to the public lists is\n>> discouraged since it is quite difficult to apply them via patch(1).\n>> Also think of non-git users...\n>\n> I think the substantially enhanced reviewability trumps non-git-users \n> who can follow the rename instructions manually (or fix up their patch \n> utility) if they insist on shunning tools that would make their life \n> easier.\n\nCan't disagree, I myself use git. ;-) But I'm also using standard\npatch(1) to test occasional patches... And sometimes linux-X tree\nisn't tracked by git (e.g. -mm otm snapshots).\n\n>> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c\n>> new file mode 100644\n>> index 0000000..ae5708e\n>> [...]\n>> diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c\n>> deleted file mode 100644\n>> index ae5708e..0000000\n>>\n>> That is, if hashes match then it was pure rename.\n>\n> I suppose, though it's not as easy to spot, and won't help in showing \n> what the differences are if there are any.\n\n..rename and changes ideally go in separate patches.\n\nIIRC this also helps git to track renames (it can easily compare\nhashes instead of guessing).\n\n-- \nAnton Vorontsov\nemail: cbouatmailru@gmail.com\nirc://irc.freenode.net/bd2\n"},{"id":"90140","messageId":"20080908215833.GC1175@lst.de","threadId":"15437","inReplyTo":"20080908212717.GA21338@oksana.dev.rtsoft.ru","subject":"Re: git apply vs. renamed files index mismatch (was: Re: [PATCH 1/4] POWERPC: Rename dma_64.c to dma.c)","fromName":"Christoph Hellwig","fromEmail":"hch@lst.de","sentAt":"2008-09-08T21:58:33Z","receivedAt":"2008-09-08T21:58:33Z","isPatch":true,"sender":{"key":"hch@lst.de","avatar":null},"body":"On Tue, Sep 09, 2008 at 01:27:17AM +0400, Anton Vorontsov wrote:\n> I always thought that posting \"-M\" patches to the public lists is\n> discouraged since it is quite difficult to apply them via patch(1).\n> Also think of non-git users...\n\nYes, it's a horrible idea.\n"},{"id":"90154","messageId":"7vej3ucf6y.fsf@gitster.siamese.dyndns.org","threadId":"15437","inReplyTo":"20080908212717.GA21338@oksana.dev.rtsoft.ru","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-09T00:53:41Z","receivedAt":"2008-09-09T00:53:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Anton Vorontsov writes:\n\n>>> 3 files changed, 201 insertions(+), 201 deletions(-)\n>>> create mode 100644 arch/powerpc/kernel/dma.c\n>>> delete mode 100644 arch/powerpc/kernel/dma_64.c\n>>\n>> Passing -M to git format-patch makes it much easier\n>\n> I always thought that posting \"-M\" patches to the public lists is\n> discouraged since it is quite difficult to apply them via patch(1).\n> Also think of non-git users...\n\nMy understanding has been that it is encouraged on the kernel mailing\nlist, because the rename format is far easier to review by showing the\ndifferences that matter to reviewers, than showing a big chunk of text\ndeleted and another big chunk of text that is similar added elsewhere.\n\nI won't comment on this any further; the use of it is strictly a list and\ncommunity policy issue.\n\n> This is still possible by comparing the hashes:\n> ...\n> That is, if hashes match then it was pure rename.\n>\n> Though, too bad git {apply,am} does not produce any warnings if there\n> are any hidden changes...\n\nBut I _do_ want to know what you mean by this comment. Your statement\nmakes it sounds as if apply/am happily and silently accept \"hidden\nchanges\" and it is a bad thing.\n\nNow what do you exactly mean by \"any hidden changes\"? Do you mean \"the\nsender did not use renaming format, the patch you fed was a one that\nremoves a huge chunk of text from one file, and adds a similarly huge\nchunk of text to another file. The changes to these files looked similar\nbut was not quite the same\"? It is all there for you to review, and\nespecially if you prefer non-renaming format, then that is what you get.\nSo I do not think that is what you are complaining about. It must be\nsomething else --- what is it?\n"},{"id":"90155","messageId":"7vabeicf3g.fsf@gitster.siamese.dyndns.org","threadId":"15437","inReplyTo":"20080908215441.GA924@oksana.dev.rtsoft.ru","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-09T00:55:47Z","receivedAt":"2008-09-09T00:55:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Anton Vorontsov writes:\n\n> ..rename and changes ideally go in separate patches.\n>\n> IIRC this also helps git to track renames (it can easily compare\n> hashes instead of guessing).\n\nIt does not help much, and it is frowned upon (at least by well educated\nusers in git circle) because such a split patch hurts reviewability.\n"},{"id":"90194","messageId":"Pine.LNX.4.64.0809091105010.27142@vixen.sonytel.be","threadId":"15437","inReplyTo":"20080908215441.GA924@oksana.dev.rtsoft.ru","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Geert Uytterhoeven","fromEmail":"geert.uytterhoeven@sonycom.com","sentAt":"2008-09-09T09:06:55Z","receivedAt":"2008-09-09T09:06:55Z","isPatch":false,"sender":{"key":"geert.uytterhoeven@sonycom.com","avatar":null},"body":"On Tue, 9 Sep 2008, Anton Vorontsov wrote:\n> On Mon, Sep 08, 2008 at 04:38:57PM -0500, Scott Wood wrote:\n> > Anton Vorontsov wrote:\n> >> I always thought that posting \"-M\" patches to the public lists is\n> >> discouraged since it is quite difficult to apply them via patch(1).\n> >> Also think of non-git users...\n> >\n> > I think the substantially enhanced reviewability trumps non-git-users \n> > who can follow the rename instructions manually (or fix up their patch \n> > utility) if they insist on shunning tools that would make their life \n> > easier.\n> \n> Can't disagree, I myself use git. ;-) But I'm also using standard\n> patch(1) to test occasional patches... And sometimes linux-X tree\n> isn't tracked by git (e.g. -mm otm snapshots).\n> \n> >> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c\n> >> new file mode 100644\n> >> index 0000000..ae5708e\n> >> [...]\n> >> diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c\n> >> deleted file mode 100644\n> >> index ae5708e..0000000\n> >>\n> >> That is, if hashes match then it was pure rename.\n> >\n> > I suppose, though it's not as easy to spot, and won't help in showing \n> > what the differences are if there are any.\n> \n> ..rename and changes ideally go in separate patches.\n\nExcept if the rename also requires some small changes (cfr. the move of\ninclude/asm-*). But if no changes are required to fix breakage caused by the\nrename, then make the changes separate.\n\n> IIRC this also helps git to track renames (it can easily compare\n> hashes instead of guessing).\n\nWith kind regards,\n\nGeert Uytterhoeven\nSoftware Architect\n\nSony Techsoft Centre Europe\nThe Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium\n\nPhone: +32 (0)2 700 8453\nFax: +32 (0)2 700 8622\nE-mail: Geert.Uytterhoeven@sonycom.com\nInternet: http://www.sony-europe.com/\n\nA division of Sony Europe (Belgium) N.V.\nVAT BE 0413.825.160 · RPR Brussels\nFortis · BIC GEBABEBB · IBAN BE41293037680010"},{"id":"90198","messageId":"20080909100628.GA15298@oksana.dev.rtsoft.ru","threadId":"15437","inReplyTo":"7vej3ucf6y.fsf@gitster.siamese.dyndns.org","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Anton Vorontsov","fromEmail":"avorontsov@ru.mvista.com","sentAt":"2008-09-09T10:06:28Z","receivedAt":"2008-09-09T10:06:28Z","isPatch":false,"sender":{"key":"avorontsov@ru.mvista.com","avatar":null},"body":"On Mon, Sep 08, 2008 at 05:53:41PM -0700, Junio C Hamano wrote:\n> Anton Vorontsov writes:\n> \n> >>> 3 files changed, 201 insertions(+), 201 deletions(-)\n> >>> create mode 100644 arch/powerpc/kernel/dma.c\n> >>> delete mode 100644 arch/powerpc/kernel/dma_64.c\n> >>\n> >> Passing -M to git format-patch makes it much easier\n> >\n> > I always thought that posting \"-M\" patches to the public lists is\n> > discouraged since it is quite difficult to apply them via patch(1).\n> > Also think of non-git users...\n> \n> My understanding has been that it is encouraged on the kernel mailing\n> list, because the rename format is far easier to review by showing the\n> differences that matter to reviewers, than showing a big chunk of text\n> deleted and another big chunk of text that is similar added elsewhere.\n> \n> I won't comment on this any further; the use of it is strictly a list and\n> community policy issue.\n> \n> > This is still possible by comparing the hashes:\n> > ...\n> > That is, if hashes match then it was pure rename.\n> >\n> > Though, too bad git {apply,am} does not produce any warnings if there\n> > are any hidden changes...\n> \n> But I _do_ want to know what you mean by this comment. Your statement\n> makes it sounds as if apply/am happily and silently accept \"hidden\n> changes\" and it is a bad thing.\n> \n> Now what do you exactly mean by \"any hidden changes\"? Do you mean \"the\n> sender did not use renaming format, the patch you fed was a one that\n> removes a huge chunk of text from one file, and adds a similarly huge\n> chunk of text to another file. The changes to these files looked similar\n> but was not quite the same\"? It is all there for you to review, and\n> especially if you prefer non-renaming format, then that is what you get.\n\nAs I said, \"index ..\" lines that git puts into patches are useful to see\nif there any changes has been made to a renamed file. So usually I don't\nhave to look through the whole patch to see if there are any changes,\nI can just look into the patch and conclude: \"this is git patch, and the\noverhead information says that it is rename-only patch. It should\nbe safe.\"\n\nNow consider the following patch (modified by hand: it should say\n+foo, but I changed it to +bar).\n\ndiff --git a/file b/file\ndeleted file mode 100644\nindex 257cc56..0000000\n--- a/file\n+++ /dev/null\n@@ -1 +0,0 @@\n-foo\ndiff --git a/file_renamed b/file_renamed\nnew file mode 100644\nindex 0000000..257cc56\n--- /dev/null\n+++ b/file_renamed\n@@ -0,0 +1 @@\n+bar\n\n\nThe \"index ...\" stuff says that there are no changes and it is\npure rename, but obviously there is a change.\n\nWhat would be great is to have is some warning (or error), that\nis: \"git-am: patch claims that it would only rename the file %s,\nbut it also changes things in that file. Somebody tried to make\na fool of you.\"\n\nMakes sense?\n\n-- \nAnton Vorontsov\nemail: cbouatmailru@gmail.com\nirc://irc.freenode.net/bd2\n"},{"id":"90221","messageId":"7vtzcp8jk0.fsf@gitster.siamese.dyndns.org","threadId":"15437","inReplyTo":"20080909100628.GA15298@oksana.dev.rtsoft.ru","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-09T14:45:19Z","receivedAt":"2008-09-09T14:45:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Anton Vorontsov writes:\n\n> Now consider the following patch (modified by hand: it should say\n> +foo, but I changed it to +bar).\n> ...\n> The \"index ...\" stuff says that there are no changes and it is\n> pure rename, but obviously there is a change.\n\nAh, I see what you mean. But in general, it is not obvious at all.\n\nIf you have the identical preimage (recorded on the LHS of the index line)\nor the patch reproduces the postimage in full (i.e. \"create a new file\"),\nyou *could* notice. It's an interesting idea from git person's point of\nview (i.e. \"would be fun to implement\"), but I doubt it would be useful in\npractice, because:\n\n (1) You often do not have the identically matching preimage;\n\n (2) More importantly, it is not unusual for people to *edit* the patch in\n their MUA (think of typofixes), after getting it out of git.\n\n (3) Even more importantly, even if you notice there is some difference,\n you cannot produce the postimage by only looking at the hash (this is\n obvious -- otherwise by definition you broke SHA-1), so you cannot\n tell *how* the patch was modified.\n\nWhat is of much more practical value to learn here in the context of this\ntopic would be that after accepting such a patch that does not use -M (so\nthat non-git people can use patch(1) to apply), a git person can still\nverify the result with \"git show -M\" to see what changes other than a pure\nrename was made by the patch.\n"},{"id":"90229","messageId":"20080909151446.GA10395@oksana.dev.rtsoft.ru","threadId":"15437","inReplyTo":"7vtzcp8jk0.fsf@gitster.siamese.dyndns.org","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Anton Vorontsov","fromEmail":"avorontsov@ru.mvista.com","sentAt":"2008-09-09T15:14:46Z","receivedAt":"2008-09-09T15:14:46Z","isPatch":false,"sender":{"key":"avorontsov@ru.mvista.com","avatar":null},"body":"On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote:\n> Anton Vorontsov writes:\n> \n> > Now consider the following patch (modified by hand: it should say\n> > +foo, but I changed it to +bar).\n> > ...\n> > The \"index ...\" stuff says that there are no changes and it is\n> > pure rename, but obviously there is a change.\n> \n> Ah, I see what you mean. But in general, it is not obvious at all.\n> \n> If you have the identical preimage (recorded on the LHS of the index line)\n> or the patch reproduces the postimage in full (i.e. \"create a new file\"),\n> you *could* notice. It's an interesting idea from git person's point of\n> view (i.e. \"would be fun to implement\"), but I doubt it would be useful in\n> practice, because:\n> \n> (1) You often do not have the identically matching preimage;\n> \n> (2) More importantly, it is not unusual for people to *edit* the patch in\n> their MUA (think of typofixes), after getting it out of git.\n\nNot for rename patches...\n\n> (3) Even more importantly, even if you notice there is some difference,\n\nJust noticing that there is a difference is enough.\n\nAs for implementing, isn't this as simple as this pseudo code:\n\nif (index_deleted_file == index_new_file)\n\tif (deleted_file != new_file)\n\t\tprintk(\"warning\\n\");\n\nIn the git-apply?\n\n-- \nAnton Vorontsov\nemail: cbouatmailru@gmail.com\nirc://irc.freenode.net/bd2\n"},{"id":"90307","messageId":"7v1vzs1xu2.fsf@gitster.siamese.dyndns.org","threadId":"15437","inReplyTo":"20080909151446.GA10395@oksana.dev.rtsoft.ru","subject":"Re: git apply vs. renamed files index mismatch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-10T03:31:01Z","receivedAt":"2008-09-10T03:31:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Anton Vorontsov writes:\n\n> On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote:\n> ...\n>> ... It's an interesting idea from git person's point of\n>> view (i.e. \"would be fun to implement\"), but I doubt it would be useful in\n>> practice, because:\n>> \n>> (1) You often do not have the identically matching preimage;\n>> \n>> (2) More importantly, it is not unusual for people to *edit* the patch in\n>> their MUA (think of typofixes), after getting it out of git.\n>\n> Not for rename patches...\n\na. Why not? Even if your patch is (totally uninteresting) pure rename, it\n is natural to review the patch before you send out, and it also is\n natural to get tempted to fix typoes, just for a straight normal patch.\n\nb. If you can expect good behaviour out of people, by declaring \"Not for\n rename patches\" as your guarantee, what's the point of this discussion?\n\n> As for implementing, isn't this as simple as this pseudo code:\n>\n> if (index_deleted_file == index_new_file)\n> \tif (deleted_file != new_file)\n> \t\tprintk(\"warning\\n\");\n>\n> In the git-apply?\n\nImplementation is easy (I said \"would be fun to code\", didn't I? --- by the\nway, how did you match \"index_deleted_file\" with \"index_new_file\"?).\n\nMy point was that it would not be reliable enough to be useful in\npractice.\n"}]}