Re: git diff: add option for omitting the contents of deletes
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 28, 2011, 23:28 UTC
- Message-ID
- <7vfwr7hh7f.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110228222352.GC5854@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 8 quoted lines
> Yeah, I guess I am just curious whether "similar enough" is really > relevant with file deletion. Obviously if you have the sha1 then > everything applies, no problem. But if you don't, how useful is the > patch text? The patch application will error out with a conflict. You > know in either case that the person wanted the file deleted. The patch > text shows you what _their_ version of the file looked like. But that's > not likely to be useful; what you really care about is what's in _your_ > version of the file, and whether that should be deleted or not.
Exactly; in order to intelligently decide if that should be deleted or not, you need to be able to judge if the deletion makes sense in the context of _your_ tree. Hopefully proposed commit log message alone may clarify if the change applies to your situation, or you need to be able to see if their version and yours are still serving similar purposes in the system (e.g. you don't want to lose the definition of a function they didn't have when they decided to remove the file saying "nobody calls any function in this library anymore").
> If you did really care about what was in their file, the giant deletion > diff is almost certainly not interesting. What you really care about is > what's different in their version versus yours.
Correct; the deletion diff has half of the necessary information (the other half being what you have).
> I'm not quite sure what lossage you mean. On the recipient's end? They > can just "git revert", no?
No, I was not particularly interested in limiting the discussion to git-using population. As I said, just like rename patch can be manually applied by first moving and then eyeballing, you can see "an instruction to delete--ok, 'rm'" to apply it and the file is gone (unlike the case where you manually did "mv"). That is what I meant by "additionally -D has lossage".
Show 25 quoted lines
>> It may make sense to show such a patch still with a bit of context, >> perhaps like this: >> >> README | 54 ------------------------------------------------------ >> 1 files changed, 0 insertions(+), 54 deletions(-) >> >> diff --git -D a/README b/README >> deleted file mode 100644 >> index 67cfeb2..0000000 >> --- a/README >> +++ /dev/null >> @@ -1,54 +0,0 @@ >> -//////////////////////////////////////////////////////////////// >> - >> - GIT - the stupid content tracker >> -... >> -the discussion following them on the mailing list give a good >> -reference for project status, development direction and >> -remaining tasks. >> >> so that the reader can have some warm and fuzzy feeling that the correct >> file is being deleted, though. > > Hmm. I think that is even worse. It's _still_ spammy, and it's broken as > a diff (the sha1 in the index line doesn't match the preimage that the
That is very much intentional; I don't think we want the format to apply mechanically. I was not talking about patch application safety at all in this thread; I already dismissed "-D" as too unreliable as a patch format to be used for conveying a change for mechanical consumption, didn't I? When you want to do so, you just generate the output without -D.
The suggestion to give some context is only for people who want to eyeball their own patches, helping them to make sure that they are removing what they wanted to remove. If they can tell from the filename alone, that is just as fine. I am not interested that deeply here; the only thing I care about is to make sure we don't have to keep carrying crappy options as if they are sane.