Re: Proposal: tell git a file has been renamed

[Felipe Contreras <felipe.contreras@gmail.com>]

Jacob Keller wrote:
> On 4/24/2023 12:25 PM, Felipe Contreras wrote:
> > Erik Cervin Edin wrote:
> >> 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.
> 
> The other end of the solution space is to try to find ways to make the
> rename detection logic more accurate. We wouldn't need to store such a
> rename if the detection gave the correct answer in the first place.

We can make it more accurate, but it will never be 100%. Sometimes being
explicit is the only way.

Cheers.

-- 
Felipe Contreras