Re: Proposal: tell git a file has been renamed

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 24, 2023, 19:25 UTC
Message-ID: <6446d78fbbe82_cd61294e5@chronos.notmuch>
In-Reply-To: <CA+JQ7M_Lv1acopOpPoHxp7mPwWMFj-7wwwDPpV7KUbwFsjpoxA@mail.gmail.com>

Erik Cervin Edin wrote:

Show 16 quoted lines

> On Mon, Apr 24, 2023 at 1:17 PM Jeremy Morton <admin@game-point.net> wrote:
> >
> > There's no getting away from the fact that this adds a lot of (IMHO
> > unnecessary) work if you've already done a rename that git can't
> > detect and have both that and a bunch of other changes sitting in the
> > index.  What feels like it would be a natural resolution in these
> > cases, though, is a "no, this remove/add is actually a rename" command.
> 
> It can definitely be both arduous and non-obvious how to deal with this.
> 
> The problem is that such a command cannot exist atm. because renames
> don't exist, they are only interpreted. So the only way to achieve
> this is to revert enough of the contents staged to the index such that
> the rename is detected. The only way to do that in a foolproof manner
> is reverting all the staged changes except the path so that the moved
> file in the index is identical to the old file in HEAD.

I agree recording renames explicitely might be a good addition to git, but the real question is how are they going to be stored in the object storage.

My guess is that it can be added in the commit object after "committer", just add a "renames" field with all the renames, or one "rename" field per rename. It would be backwards compatible because any field can be added this way.

How to generate these fields is a separate issue: first things first.

-- 
Felipe Contreras