From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Scott Wood <scottwood@freescale.com>,
git@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: git apply vs. renamed files index mismatch
Date: Tue, 9 Sep 2008 14:06:28 +0400 [thread overview]
Message-ID: <20080909100628.GA15298@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <7vej3ucf6y.fsf@gitster.siamese.dyndns.org>
On Mon, Sep 08, 2008 at 05:53:41PM -0700, Junio C Hamano wrote:
> Anton Vorontsov <avorontsov@ru.mvista.com> writes:
>
> >>> 3 files changed, 201 insertions(+), 201 deletions(-)
> >>> create mode 100644 arch/powerpc/kernel/dma.c
> >>> delete mode 100644 arch/powerpc/kernel/dma_64.c
> >>
> >> Passing -M to git format-patch makes it much easier
> >
> > I always thought that posting "-M" patches to the public lists is
> > discouraged since it is quite difficult to apply them via patch(1).
> > Also think of non-git users...
>
> My understanding has been that it is encouraged on the kernel mailing
> list, because the rename format is far easier to review by showing the
> differences that matter to reviewers, than showing a big chunk of text
> deleted and another big chunk of text that is similar added elsewhere.
>
> I won't comment on this any further; the use of it is strictly a list and
> community policy issue.
>
> > This is still possible by comparing the hashes:
> > ...
> > That is, if hashes match then it was pure rename.
> >
> > Though, too bad git {apply,am} does not produce any warnings if there
> > are any hidden changes...
>
> But I _do_ want to know what you mean by this comment. Your statement
> makes it sounds as if apply/am happily and silently accept "hidden
> changes" and it is a bad thing.
>
> Now what do you exactly mean by "any hidden changes"? Do you mean "the
> sender did not use renaming format, the patch you fed was a one that
> removes a huge chunk of text from one file, and adds a similarly huge
> chunk of text to another file. The changes to these files looked similar
> but was not quite the same"? It is all there for you to review, and
> especially if you prefer non-renaming format, then that is what you get.
As I said, "index .." lines that git puts into patches are useful to see
if there any changes has been made to a renamed file. So usually I don't
have to look through the whole patch to see if there are any changes,
I can just look into the patch and conclude: "this is git patch, and the
overhead information says that it is rename-only patch. It should
be safe."
Now consider the following patch (modified by hand: it should say
+foo, but I changed it to +bar).
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
The "index ..." stuff says that there are no changes and it is
pure rename, but obviously there is a change.
What would be great is to have is some warning (or error), that
is: "git-am: patch claims that it would only rename the file %s,
but it also changes things in that file. Somebody tried to make
a fool of you."
Makes sense?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Scott Wood <scottwood@freescale.com>,
Becky Bruce <becky.bruce@freescale.com>,
linuxppc-dev@ozlabs.org, git@vger.kernel.org
Subject: Re: git apply vs. renamed files index mismatch
Date: Tue, 9 Sep 2008 14:06:28 +0400 [thread overview]
Message-ID: <20080909100628.GA15298@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <7vej3ucf6y.fsf@gitster.siamese.dyndns.org>
On Mon, Sep 08, 2008 at 05:53:41PM -0700, Junio C Hamano wrote:
> Anton Vorontsov <avorontsov@ru.mvista.com> writes:
>
> >>> 3 files changed, 201 insertions(+), 201 deletions(-)
> >>> create mode 100644 arch/powerpc/kernel/dma.c
> >>> delete mode 100644 arch/powerpc/kernel/dma_64.c
> >>
> >> Passing -M to git format-patch makes it much easier
> >
> > I always thought that posting "-M" patches to the public lists is
> > discouraged since it is quite difficult to apply them via patch(1).
> > Also think of non-git users...
>
> My understanding has been that it is encouraged on the kernel mailing
> list, because the rename format is far easier to review by showing the
> differences that matter to reviewers, than showing a big chunk of text
> deleted and another big chunk of text that is similar added elsewhere.
>
> I won't comment on this any further; the use of it is strictly a list and
> community policy issue.
>
> > This is still possible by comparing the hashes:
> > ...
> > That is, if hashes match then it was pure rename.
> >
> > Though, too bad git {apply,am} does not produce any warnings if there
> > are any hidden changes...
>
> But I _do_ want to know what you mean by this comment. Your statement
> makes it sounds as if apply/am happily and silently accept "hidden
> changes" and it is a bad thing.
>
> Now what do you exactly mean by "any hidden changes"? Do you mean "the
> sender did not use renaming format, the patch you fed was a one that
> removes a huge chunk of text from one file, and adds a similarly huge
> chunk of text to another file. The changes to these files looked similar
> but was not quite the same"? It is all there for you to review, and
> especially if you prefer non-renaming format, then that is what you get.
As I said, "index .." lines that git puts into patches are useful to see
if there any changes has been made to a renamed file. So usually I don't
have to look through the whole patch to see if there are any changes,
I can just look into the patch and conclude: "this is git patch, and the
overhead information says that it is rename-only patch. It should
be safe."
Now consider the following patch (modified by hand: it should say
+foo, but I changed it to +bar).
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
The "index ..." stuff says that there are no changes and it is
pure rename, but obviously there is a change.
What would be great is to have is some warning (or error), that
is: "git-am: patch claims that it would only rename the file %s,
but it also changes things in that file. Somebody tried to make
a fool of you."
Makes sense?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2008-09-09 10:06 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-08 19:09 [PATCH 0/4] POWERPC: 32/64-bit DMA code merge and cleanup Becky Bruce
2008-09-08 19:09 ` [PATCH 1/4] POWERPC: Rename dma_64.c to dma.c Becky Bruce
2008-09-08 19:09 ` [PATCH 2/4] POWERPC: Move iommu dma ops from dma.c to dma-iommu.c Becky Bruce
2008-09-08 19:09 ` [PATCH 3/4] POWERPC: Drop archdata numa_node Becky Bruce
2008-09-08 19:09 ` [PATCH 4/4] POWERPC: Merge 32 and 64-bit dma code Becky Bruce
2008-09-08 22:03 ` Christoph Hellwig
2008-09-09 10:54 ` Benjamin Herrenschmidt
2008-09-09 14:39 ` Becky Bruce
2008-09-09 20:45 ` Christoph Hellwig
2008-09-09 22:10 ` Benjamin Herrenschmidt
2008-09-09 22:13 ` Christoph Hellwig
2008-09-09 22:17 ` Becky Bruce
2008-09-12 20:34 ` [PATCH V2 " Becky Bruce
2008-10-13 14:49 ` Josh Boyer
2008-10-13 15:41 ` Josh Boyer
2008-10-13 18:06 ` Kumar Gala
2008-10-13 18:21 ` Josh Boyer
2008-10-13 18:22 ` Kumar Gala
2008-10-13 23:30 ` Benjamin Herrenschmidt
2008-10-14 1:52 ` Kumar Gala
2008-10-14 10:24 ` Josh Boyer
2008-10-14 12:05 ` Benjamin Herrenschmidt
2008-10-14 15:45 ` Becky Bruce
2008-10-13 23:30 ` Benjamin Herrenschmidt
2008-09-08 21:57 ` [PATCH 2/4] POWERPC: Move iommu dma ops from dma.c to dma-iommu.c Christoph Hellwig
2008-09-12 15:32 ` Becky Bruce
2008-09-08 19:18 ` [PATCH 1/4] POWERPC: Rename dma_64.c to dma.c Scott Wood
2008-09-08 21:27 ` git apply vs. renamed files index mismatch (was: Re: [PATCH 1/4] POWERPC: Rename dma_64.c to dma.c) Anton Vorontsov
2008-09-08 21:27 ` Anton Vorontsov
2008-09-08 21:38 ` git apply vs. renamed files index mismatch Scott Wood
2008-09-08 21:38 ` Scott Wood
2008-09-08 21:54 ` Anton Vorontsov
2008-09-08 21:54 ` Anton Vorontsov
2008-09-09 0:55 ` Junio C Hamano
2008-09-09 0:55 ` Junio C Hamano
2008-09-09 9:06 ` Geert Uytterhoeven
2008-09-09 9:06 ` Geert Uytterhoeven
2008-09-08 21:58 ` git apply vs. renamed files index mismatch (was: Re: [PATCH 1/4] POWERPC: Rename dma_64.c to dma.c) Christoph Hellwig
2008-09-08 21:58 ` Christoph Hellwig
2008-09-09 0:53 ` git apply vs. renamed files index mismatch Junio C Hamano
2008-09-09 0:53 ` Junio C Hamano
2008-09-09 10:06 ` Anton Vorontsov [this message]
2008-09-09 10:06 ` Anton Vorontsov
2008-09-09 14:45 ` Junio C Hamano
2008-09-09 14:45 ` Junio C Hamano
2008-09-09 15:14 ` Anton Vorontsov
2008-09-09 15:14 ` Anton Vorontsov
2008-09-10 3:31 ` Junio C Hamano
2008-09-10 3:31 ` Junio C Hamano
2008-09-08 21:56 ` [PATCH 0/4] POWERPC: 32/64-bit DMA code merge and cleanup Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080909100628.GA15298@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.