From: Jacob Keller <jacob.e.keller@intel.com>
To: Felipe Contreras <felipe.contreras@gmail.com>,
Erik Cervin Edin <erik@cervined.in>,
Jeremy Morton <admin@game-point.net>
Cc: Chris Torek <chris.torek@gmail.com>, <git@vger.kernel.org>
Subject: Re: Proposal: tell git a file has been renamed
Date: Mon, 24 Apr 2023 12:44:47 -0700 [thread overview]
Message-ID: <26c4306d-f0f1-a2a6-55a5-6bb10c77cc0f@intel.com> (raw)
In-Reply-To: <6446d78fbbe82_cd61294e5@chronos.notmuch>
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.
You can already kind of do this by modifying the similarity values when
searching for renames: the -M option takes a percentage for how similar
files need to be in order for it to be a rename. The default is 50%,
meaning that the files have to stay at least 50% the same in order to be
considered a rename.
One potential in the case for renames which also must change class
names, etc could be a mechanism to say "treat it as a rename if the
content is the same after performing this replacement", where you could
specify what string is being replaced in the rename somehow.
This could easily be done for reviewing a previous change, but
specifically how to *store* this expression so you don't need to
remember such values in the future is a bigger challenge.
next prev parent reply other threads:[~2023-04-24 19:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-22 18:01 Proposal: tell git a file has been renamed Jeremy Morton
2023-04-22 18:54 ` rsbecker
2023-04-22 19:44 ` Jeremy Morton
2023-04-22 19:47 ` rsbecker
2023-04-22 19:54 ` Jeremy Morton
2023-04-22 22:09 ` rsbecker
2023-04-23 9:38 ` Erik Cervin Edin
2023-04-23 21:01 ` Kristoffer Haugsbakk
2023-04-24 1:43 ` Chris Torek
2023-04-24 10:10 ` Jeremy Morton
2023-04-24 10:24 ` Chris Torek
2023-04-24 10:49 ` Erik Cervin Edin
2023-04-24 11:17 ` Jeremy Morton
2023-04-24 14:00 ` Erik Cervin Edin
2023-04-24 14:42 ` Jeremy Morton
2023-04-24 19:25 ` Felipe Contreras
2023-04-24 19:44 ` Jacob Keller [this message]
2023-04-24 20:00 ` Felipe Contreras
2023-04-26 19:08 ` Jacob Keller
2023-04-26 20:39 ` Junio C Hamano
2023-05-11 13:44 ` Erik Cervin Edin
2023-04-24 18:26 ` Junio C Hamano
2023-04-24 19:41 ` Junio C Hamano
2023-04-24 20:05 ` Jeremy Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26c4306d-f0f1-a2a6-55a5-6bb10c77cc0f@intel.com \
--to=jacob.e.keller@intel.com \
--cc=admin@game-point.net \
--cc=chris.torek@gmail.com \
--cc=erik@cervined.in \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).