public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Junio C Hamano <gitster@pobox•com>
To: Ben Knoble <ben.knoble@gmail•com>
Cc: Chris Torek <chris.torek@gmail•com>,
	 Frieder Hannenheim <mail@fhannenheim•net>,
	 git@vger•kernel.org
Subject: Re: git mv after the fact
Date: Fri, 29 May 2026 05:36:21 +0900	[thread overview]
Message-ID: <xmqq5x47jmpm.fsf@gitster.g> (raw)
In-Reply-To: <1FEDBC47-5DDB-4C42-A7C7-695630D330BF@gmail.com> (Ben Knoble's message of "Thu, 28 May 2026 10:28:51 -0400")

Ben Knoble <ben.knoble@gmail•com> writes:

>> Le 27 mai 2026 à 19:24, Junio C Hamano <gitster@pobox•com> a écrit :
>> 
>> Chris Torek <chris.torek@gmail•com> writes:
>> 
>>>> Chris Torek <chris.torek@gmail•com> writes:
>>>>> A flag for "git mv" would be convenient (and slightly moreefficient ...
>>>> 
>>> 
>>> On Tue, May 26, 2026 at 8:09 PM Junio C Hamano <gitster@pobox•com> wrote:
>>>> May be convenient, but I do not get the "efficient" part.
>>> 
>>> A normal `git mv` renames the index entry and the file in the working
>>> tree without running `git add` on the *contents*, so there's no new hash
>>> computation.  Presumably a `git mv --after foo bar` would do the same: verify
>>> that there is no existing `bar` in the index, that there is an existing `foo` in
>>> the index, and that there is no `foo` but there is a `bar` in the working tree,
>>> and then it would rename (add-and-remove, really, because of sorting)
>>> the index entry, without scanning the working tree contents.
>>> 
>>> In other words, we skip reading the 3 terabyte file, or whatever.
>> 
>> Yup, that matches what I wrote.  We do not rehash and we only write
>> the index just once.
>
> One thing I wondered: if we don’t have an exact move but assume (by not hashing), doesn’t that mean the index would differ from what’s on disk? I originally thought that might be a problem, but the more I thought the more I realized that’s a fairly typical state anyway.
>
> Just seemed like a potential footgun to me, but perhaps not worth worrying about. 

Good point.  Actually with or without --after/--cached, we do not
have to rehash, and more importantly, we should not rehash.

As you can do this already

    $ date >old.txt
    $ git add old.txt
    $ date >>old.txt
    ... now old.txt is _dirty_
    $ git mv old.txt new.txt

I do not think it is unusual to have the contents you have in your
working tree files diverge from the contents you last 'git add'ed to
the index.  You do *not* want to rehash.  The index entry for new.txt
must be left not-up-to-date, which is achieved in the above sequence
by retaining the file timestamp of old.txt at the "git add" time
even after "git mv" (i.e. new.txt has the timestamp and size of the
old.txt after it got the second "date" output, the index entry
records one generation old one, and would not match).  If we do the
"index-entry only" move, i.e.

    $ date >old.txt
    $ git add old.txt
    $ date >>old.txt
    ... now old.txt is _dirty_
    $ mv old.txt new.txt
    ... oops, we forgot to tell git
    $ git mv --cached old.txt new.txt

we need to make sure that we leave the cache entry dirty for
new.txt in the index.

next prev parent reply	other threads:[~2026-05-28 20:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26 12:57 git mv after the fact Frieder Hannenheim
2026-05-26 16:40 ` Chris Torek
2026-05-26 16:50   ` Frieder Hannenheim
2026-05-26 21:29   ` Ben Knoble
2026-05-27  3:09   ` Junio C Hamano
2026-05-27  3:19     ` Chris Torek
2026-05-27 23:22       ` Junio C Hamano
2026-05-28 14:28         ` Ben Knoble
2026-05-28 20:36           ` Junio C Hamano [this message]
2026-05-27  3:27     ` Tim Tassonis

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=xmqq5x47jmpm.fsf@gitster.g \
    --to=gitster@pobox$(echo .)com \
    --cc=ben.knoble@gmail$(echo .)com \
    --cc=chris.torek@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=mail@fhannenheim$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox