From: Junio C Hamano Date: Wed, 27 May 2026 23:22:22 GMT Subject: Re: git mv after the fact Message-ID: <877bootp3l.fsf@gitster.g> In-Reply-To: Chris Torek writes: >> Chris Torek writes: >>> A flag for "git mv" would be convenient (and slightly moreefficient ... >> > > On Tue, May 26, 2026 at 8:09 PM Junio C Hamano 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. > Anyway, comparing to `git rm --cached`: > >> I think the requested "feature" is not all that outrageous. It >> would be a similar value as a morning-after correction measure for >> "oops, I moved the file in the filesystem without telling Git". > > I agree, but I also don't see it as valuable enough to bother > writing a proper implementation. Yup, I was merely agreeing with your "convenient" comment. I do not think it is such a high-priority item for any active developers among us to drop something they are doing and writing it instead.