git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: Christian Couder <christian.couder@gmail.com>,
	ZheNing Hu <adlternative@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [QUESTION] how to diff one blob with nothing
Date: Fri, 04 Aug 2023 12:00:11 -0700	[thread overview]
Message-ID: <xmqqmsz6ljk4.fsf@gitster.g> (raw)
In-Reply-To: <ZM1EvGVGv2ZYrpuT@nand.local> (Taylor Blau's message of "Fri, 4 Aug 2023 14:34:36 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> On Fri, Aug 04, 2023 at 10:28:53AM +0200, Christian Couder wrote:
>> On Fri, Aug 4, 2023 at 6:42 AM ZheNing Hu <adlternative@gmail.com> wrote:
>>
>> > Actually, there is no need to support a default empty blob.
>> > For example, with the command "git diff --no-index <file> /dev/null",
>> > it can compare a file with /dev/null, but it can only compare <file>
>> > and not <oid>.
>> > Therefore, using commands like "git diff <oid> /dev/null",
>> > "git diff --no-index <oid> /dev/null", or even "git diff <oid> --stdin"
>> > could potentially solve this issue.
>>
>> Maybe it would be clearer to have a new option, called for example
>> "--blob-vs-file", for that then. It could support both:
>>
>> $ git diff --blob-vs-file <blob> <file>
>>
>> and:
>>
>> $ git diff --blob-vs-file <file> <blob>
>
> Hmm. This feels like a case of trying to teach 'git diff' to do too
> much.

Worse yet, I do not quite get the original use case in the first
place.  What is the series of diff output that result in comparing a
random pair of blob object names going to be used for?

The reply to <ZMKtcaN7xYaTtkcI@nand.local> says that the original
use case was to express the evolution of a single path since its
creation until its removal, but the thing is, a diff with an empty
blob and a creation or a deletion event are expressed differently in
the patch output, exactly because the patch has to be able to
express "before this change, a file with zero byte content was
there" and "before this change, there was nothing at this path"
(vice versa for contents-removal vs deletion).

For that reason, I have a hard time to find any merit in the earlier
complaint that said "can be achieved by manually adding them, but it
is not very compatible with the original logic", whatever the
"original logic" refers to.  If creation needs to be recorded as
creation and not as a change from an empty and existing blob, there
has to be something that needs to be manually done to turn the
latter (which is the only thing "diff" between two blobs or even a
blob and a file can give) into the former *anyway*.  Whatever the
thing that is looping over the history/evoluation of a single path
needs to have a three-arm switch for each iteration to deal with
creation, modification, and removal, and iterating over the contents
of the files and prefixing "+" or "-" on each and every line would
be the _easiest_ part of such a necessary tweak to turn "diff
between an empty contents and something else" into "creation or
deletion of a file."


  reply	other threads:[~2023-08-04 19:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19  9:59 [QUESTION] how to diff one blob with nothing ZheNing Hu
2023-07-19 16:15 ` Junio C Hamano
2023-07-26 18:00   ` ZheNing Hu
2023-07-26 18:23     ` Junio C Hamano
2023-07-27 17:46       ` Taylor Blau
2023-07-28  3:40         ` ZheNing Hu
2023-08-03  5:16           ` ZheNing Hu
2023-08-03 15:24             ` Taylor Blau
2023-08-04  2:28               ` ZheNing Hu
2023-08-04  8:28                 ` Christian Couder
2023-08-04 18:34                   ` Taylor Blau
2023-08-04 19:00                     ` Junio C Hamano [this message]
2023-08-05  8:27                       ` ZheNing Hu
2023-07-27 17:13     ` Konstantin Khomoutov
2023-07-28  3:35       ` ZheNing Hu

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=xmqqmsz6ljk4.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=adlternative@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    /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).