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@xxxxxxxxxxxxxx> 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
