Re: git diff: add option for omitting the contents of deletes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 28, 2011 at 08:31:55AM +0100, Michael J Gruber wrote:

> > Junio C Hamano <gitster@xxxxxxxxx> writes:
> >>
> >> There is a big difference: -M and -C lets your recipient reproduce the
> >> state using the change you are trying to convey with the diff output in
> >> either direction (iow, "apply -R" works), but your "-D" would not have
> >> that property.
>
> [...]
>
> Yes, it is purely intended as "for viewing by humans". Even in the
> forward direction saying "delete that path" is different from saying
> "delete that content from that path", i.e. "diff -D" output may apply
> without conflicts in cases where "diff" output does not.
> 
> 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".

> Reminds me of my failed attempt to make the diff output for symlinks
> more human-friendly. The latter can be solved with textconv, though.

I am still carrying around my "symlinks as a special class of diff"
patches if you are interested:

  https://github.com/peff/git/tree/jk/userdiff-symlinks

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]