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

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

 



Why not just make it reversible then?

$ git diff -M
diff --git a/foo b/bar
similarity index 100%
rename from foo
rename to bar

is nonreversible without git already (i.e. does not work with plain
patch AFAIK).

Adding

$ git diff -D
diff --git a/foo b/foo
deleted file mode 100644
delete foo

would be neither less nor more reversible -- it would also only work
with git apply
(assuming that apply is amended accordingly).

Cognitive burdens aside, the "delete foo" output is both
more explicit and shorter anyway. Occam's razor FTW :)!

Junio, I won't push this further, so it's a final call -- if you give -1,
then let -D fall to the colourless abyss of oblivion :), if +1 or +0,
I'll see if I can come up with a patch.

Best regards,
MS

On Mon, Feb 28, 2011 at 1:07 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>>
>>> Wasn't the pager invented for sifting through output which has to be
>>> several pages, but not not for that which could be more concise? ;)
>>>
>>> In fact, -D would be quite analogous to -M and -C in that respect.
>>
>> 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.
>
> Having said that we have always valued "reversibility" and a casual -D is
> not in line with that principle, I don't have a strong objection if the
> new mode of operation is marked clearly as "nonusable if you are trying to
> produce appliable diff (iow, don't send such a patch to mailing list--it
> is for viewing purposes only)", treating it just like the --color-words
> and the --stat options (there isn't even need to mark these as unusable
> for that purpose, as people with common sense would be able to guess).
>
> If we were to do this, it probably is a good idea to apply that for a
> typechange patch (the one that is produced when a symlink turns into a
> regular file and vice versa) as well.  It also might make sense to apply
> the similar principle to shorten the output with -B when a rewrite patch
> is expressed as a single hunk patch that removes everything old and then
> adds everthing new.
>
--
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]