From: Linus Torvalds <torvalds@osdl.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Make sure diff-helper can tell rename/copy in the new diff-raw format.
Date: Mon, 23 May 2005 07:49:01 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0505230736180.2307@ppc970.osdl.org> (raw)
In-Reply-To: <7vfywe769d.fsf@assigned-by-dhcp.cox.net>
On Mon, 23 May 2005, Junio C Hamano wrote:
>
> This adds tests to make sure that diff-helper can tell renames
> from copies using the same "everything but the last one are
> copies and the last one is either rename or stay" logic.
Btw, I still disagree with this notion that the order of the use of the
names makes a difference.
I think that when we generate a diff, we should always have the _option_
to make sure that we generate it in a format where you can apply it
"incrementally". But I disagree with the notion that it's something
fundamental, and in fact, I even think that it's not necessarily a good
default.
For example, let's say that you have modified "fileA" _and_ you have
created a "fileB" that is a copy of the original "fileA" with some _other_
slight modifications. We'll call the SHA1's involved "sha_A", "sha_A'" and
"sha_B"
I think it's perfectly valid to say
:100644 100644 <sha_A> <sha_A'> M fileA fileA
:100644 100644 <sha_A> <sha_B> C89 fileA fileB
which says "fileA" was modified from orig-A to new-A, and "fileB" is a
copy based on orig-A.
(I've used a new syntax just to confuse the issue, with the extra field
for "what happened", aka "M" for "modify", "C89" for "copy a 89% similar
file").
Now, when the above is turned into a "diff", that diff is no longer
something you can apply "incrementally" - you have to apply it as if
you're applying all differences to the "original tree". But the thing is,
that's actually what I _want_, because I was planning on writing a tool
that applies patches that applies them all-or-nothing.
Also, it turns out that this kind of "non-incremental" diff is the kind
that I personally want to see as a _human_, because quite frankly, my
brain-capacity is that of a demented ocelot, and I can't _remember_ what
happened in other parts of the diff. I much prefer the stateless "oh, this
file X is in that relation Y to the previous version of file Z".
I do that partly because I actually routinely edit patches. If you have
the incremental format, that's practically impossible, while the stateless
version is fine.
See?
So I think all the clever "don't re-use files we have modified" etc is
actually wrong. If you want to make a traditional diff that can be applied
with normal "patch", you just don't use the -M or -C flags.
Linus
next prev parent reply other threads:[~2005-05-23 14:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-23 7:26 [PATCH] Make sure diff-helper can tell rename/copy in the new diff-raw format Junio C Hamano
2005-05-23 14:49 ` Linus Torvalds [this message]
2005-05-23 18:43 ` Junio C Hamano
2005-05-23 19:03 ` Linus Torvalds
2005-05-23 19:16 ` Linus Torvalds
2005-05-23 21:55 ` [PATCH] diff-raw format update take #2 Junio C Hamano
2005-05-23 22:08 ` Junio C Hamano
2005-05-24 0:12 ` Chris Wedgwood
2005-05-24 0:25 ` Junio C Hamano
2005-05-24 0:31 ` Chris Wedgwood
2005-05-24 0:45 ` Junio C Hamano
2005-05-24 1:03 ` Linus Torvalds
2005-05-24 1:05 ` Chris Wedgwood
2005-05-24 1:29 ` David Lang
2005-05-24 1:33 ` Chris Wedgwood
2005-05-24 1:39 ` Thomas Glanzmann
[not found] ` <20050524013947.ADFEE528F53@taniwha.stupidest.org>
2005-05-24 1:44 ` Thomas Glanzmann
2005-05-24 1:50 ` Linus Torvalds
2005-05-24 0:51 ` Linus Torvalds
2005-05-26 0:55 ` [PATCH] Make sure diff-helper can tell rename/copy in the new diff-raw format Junio C Hamano
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=Pine.LNX.4.58.0505230736180.2307@ppc970.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).