Re: Proposal: tell git a file has been renamed

From: Chris Torek <chris.torek@gmail.com>
Date: Apr 24, 2023, 10:24 UTC
Message-ID: <CAPx1GvfszM00DzW9JxxoNZfnM3-eUJCxPArUzwFV7E+t==cJ4g@mail.gmail.com>
In-Reply-To: <74a361fd-4ee6-f362-8d49-92417f0e2dac@game-point.net>

On Mon, Apr 24, 2023 at 3:15 AM Jeremy Morton <admin@game-point.net> wrote:

> On 24/04/2023 02:43, Chris Torek wrote:
> > ... Alternatively, we could have a
> > command -- similar to `git commit --only` in effect

> I'm not sure what the utility of the --only thing would be - to detect
> renames that didn't have changed content so that all renames could be
> done in one pre-commit?

I mentioned `git commit --only` here just to point out that `git commit` already has the ability to make a commit without using the current index as the new commit's source. A "just do renames" commit operation (in spite of other changes already made in the current index) would need similar functionality.

Exactly how this might work, I haven't defined.

> Huh, I just read the docs on [hg mv]... does that mean hg already has
> this functionality of being able to store a "this was renamed" marker
> in its index?

Mercurial does not have an index in the first place. The internal structure of the Mercurial database is an append-only series of changelongs, with files stored as deltas from the previous version of that file (with some exceptions). Files are listed in a manifest, and renaming a file preserves the file's identity despite the change of name.

(This internal format is very different from Git's. Git is a content-addressable file system, rather than an append-only changelog.)

Chris