git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] diffcore-delta: avoid ignoring final 'line' of file
Date: Thu, 18 Jan 2024 19:06:36 -0800	[thread overview]
Message-ID: <xmqqjzo6m37n.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BEaYkAPphh06R1HrfD03WTv5uy-2q-T0ZMZaxo9hfXv-g@mail.gmail.com> (Elijah Newren's message of "Thu, 18 Jan 2024 17:54:00 -0800")

Elijah Newren <newren@gmail.com> writes:

>> Heh, I was hoping that we should be able to use "diff --name-only".
>>
>>  $ git mv Makefile Breakfile
>>  $ git diff --name-only -M HEAD
>>  Breakfile
>>  $ git reset --hard
>>  $ git rm Makefile
>>  $ >Breakfile && git add Breakfile
>>  $ git diff --name-only -M HEAD
>>  Breakfile
>>  Makefile
>>  $ git reset --hard
>
> I guess we could, since the only thing in this repository is a file
> which is being renamed, and we can then deduce based on the setup that
> the change we expected must have happened.
>
> However, I didn't like the deduce bit; since --name-only only lists
> one of the two filenames and doesn't provide any hint that the change
> involved is a rename, it felt to me like using --name-only would make
> the test not really be a rename test.

Hmph, I am not quite seeing what you are saying.  If the "mv" from
Makefile to Breakfile in the above example is between preimage and
postimage that are similar enough, then we will see "one" paths,
i.e. the file in the "after" side of the diff.  But if the "mv" from
Makefile to Breakfile involves too large a content change (like,
say, going from 3800+ lines to an empty file, in the second example
above), then because such a change from Makefile to Breakfile is too
dissimilar, we do not judge it as "renamed" and show "two" paths.  I
do not quite see where we need to "deduce".



  reply	other threads:[~2024-01-19  3:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 20:47 [PATCH] diffcore-delta: avoid ignoring final 'line' of file Elijah Newren via GitGitGadget
2024-01-11 21:45 ` Taylor Blau
2024-01-11 23:00 ` Junio C Hamano
2024-01-13  1:45   ` Elijah Newren
2024-01-13  6:21     ` Junio C Hamano
2024-01-19  1:54       ` Elijah Newren
2024-01-19  3:06         ` Junio C Hamano [this message]
2024-01-19  5:05           ` Elijah Newren
2024-01-19  6:27             ` Junio C Hamano
2024-01-13  4:26 ` [PATCH v2] " Elijah Newren via GitGitGadget

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=xmqqjzo6m37n.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=newren@gmail.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).