From: Michael J Gruber <git@drmicha.warpmail.net>
To: Jeff King <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Mart Sõmermaa" <mrts.pydev@gmail.com>,
git@vger.kernel.org
Subject: Re: git diff: add option for omitting the contents of deletes
Date: Mon, 28 Feb 2011 13:32:35 +0100 [thread overview]
Message-ID: <4D6B95E3.7040603@drmicha.warpmail.net> (raw)
In-Reply-To: <20110228122335.GB5197@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 28.02.2011 13:23:
> On Mon, Feb 28, 2011 at 07:17:26AM -0500, Jeff King wrote:
>
>>> That aspect is similar to -M and -C, though - unless we check the sha1
>>> of the blobs before applying the patch (which would be possible for -D
>>> also) - do we?
>>
>> Yes, I think we do check the sha1s for a "-M" patch. And we should do so
>> for a "-D" patch, too. Which would make it just as likely to conflict as
>> a version with the actual patch content, _except_ that it relies on the
>> recipient having that sha1.
>>
>> I don't see how "-D" is any less reversible than -M or -C, though. If I
>> get your -D patch, I use the index line to see that the blob went from
>> 1234abcd to 0000000, check that we are at 1234abcd, and then delete the
>> file. To reverse it, I reinstate 1234abcd from nothing (and conflict if
>> the file exists). _Neither_ case works without the sha1.
>>
>> So I think the problem is not about "this cannot be reversed" but about
>> "the recipient must have your sha1 to make sense of it, in either
>> direction". Which is the same case as with "-M" and "-C", and why we
>> have long cautioned about their use on mailing lists. But the right rule
>> is not "do not use on mailing lists" but rather "do not use on mailing
>> lists for projects where the recipients will not be using git to apply".
>
> Actually, thinking on this a bit more, I guess "-M" and "-C" are usable
> without the sha1. In fact, we don't even provide it for a strict 100%
> rename, and for a rename-with-patch, you can apply the patch, assuming
> you have the original file in any form. So they are really about "is
> your recipient using git", not "is your recipient using git _and_ will
> he/she have the right sha1".
$ git mv Makefile Dofile
$ git staged # yadayada
diff --git c/Makefile i/Dofile
similarity index 100%
rename from Makefile
rename to Dofile
Same with copy.
But that's not good, is it? I mean, Alice sends me her "copy patch" and
I send her my Makefile patch, both on top of the same base. We both
apply each other's patch cleanly. We end up with different "Dofile".
Checking the sha1 would prevent this. It's no surprise that patch
application is non-commutative, but shouldn't we catch this?
Michael
next prev parent reply other threads:[~2011-02-28 12:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-26 13:16 git diff: add option for omitting the contents of deletes Mart Sõmermaa
2011-02-26 20:11 ` Junio C Hamano
2011-02-27 14:41 ` Michael J Gruber
2011-02-27 22:33 ` Mart Sõmermaa
2011-02-28 9:58 ` Michael J Gruber
2011-02-28 10:51 ` Mart Sõmermaa
2011-02-27 22:54 ` Junio C Hamano
2011-02-27 23:07 ` Junio C Hamano
2011-02-28 7:31 ` Michael J Gruber
2011-02-28 12:17 ` Jeff King
2011-02-28 12:23 ` Jeff King
2011-02-28 12:32 ` Michael J Gruber [this message]
2011-02-28 12:59 ` Jeff King
2011-02-28 13:05 ` Michael J Gruber
2011-02-28 21:54 ` Jeff King
2011-02-28 18:11 ` Junio C Hamano
2011-02-28 22:23 ` Jeff King
2011-02-28 23:28 ` Junio C Hamano
2011-03-01 0:11 ` Junio C Hamano
2011-03-07 20:38 ` Mart Sõmermaa
2011-03-08 7:14 ` Michael J Gruber
2011-03-08 19:49 ` Junio C Hamano
2011-03-08 21:25 ` Mart Sõmermaa
2011-03-08 21:31 ` Jeff King
2011-02-28 12:42 ` symling diff driver (Was: Re: git diff: add option for omitting the contents of deletes) Michael J Gruber
2011-02-28 13:08 ` Jeff King
2011-02-28 15:26 ` [PATCH/WIP] attr: make attributes depend on file type Michael J Gruber
2011-02-28 17:30 ` Jeff King
2011-02-28 17:48 ` Junio C Hamano
2011-03-01 7:46 ` Michael J Gruber
2011-02-28 10:45 ` git diff: add option for omitting the contents of deletes Mart Sõmermaa
2011-02-28 16:10 ` Michael J Gruber
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=4D6B95E3.7040603@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mrts.pydev@gmail.com \
--cc=peff@peff.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).