On Sat, Jul 23, 2022 at 10:10:11PM -0700, Elijah Newren wrote:

On Fri, Jul 22, 2022 at 1:42 PM Michal Suchánek [off-list ref] wrote:

quoted

On Fri, Jul 22, 2022 at 09:08:56PM +0100, Philip Oakley wrote:

quoted

On 21/07/2022 19:58, Hilco Wijbenga wrote:

quoted

On Thu, Jul 21, 2022 at 9:39 AM Phillip Susi [off-list ref] wrote:

quoted

Ęvar Arnfjörš Bjarmason [off-list ref] writes:

quoted

This has come up a bunch of times. I think that the thing git itself
should be doing is to lean into the same notion that we use for tracking
renames. I.e. we don't, we analyze history after-the-fact and spot the
renames for you.

I've never been a big fan of that quality of git because it is
inherently unreliable.

Indeed, which would be fine ... if there were a way to tell Git, "no
this is not a rename" or "hey, you missed this rename" but there
isn't.

Reading previous messages, it seems like the
after-the-fact-rename-heuristic makes the Git code simpler. That is a
perfectly valid argument for not supporting "explicit" renames but I
have seen several messages from which I inferred that rename handling
was deemed a "solved problem". And _that_, at least in my experience,
is definitely not the case.

Part of the rename problem is that there can be many different routes to
the same result, and often the route used isn't the one 'specified' by
those who wish a complicated rename process to have happened 'their
way', plus people forget to record what they actually did. Attempting to
capture what happened still results major gaps in the record.

Doesn't git have rebase?

It is not required that the rename is captured perfectly every time so
long as it can be amended later.

"so long as".  Therefore, since it can't be amended after the commit
is accepted/merged, it is required that this auxiliary data be
captured perfectly before that time if it's going to be captured at
all.

Did I read that right?

Or it will be broken after it is merged, just as many other things in
commits that are accepted into history that is not to be modified
anymore.

The only point I can see here is that if there is any user-crafted
metadata that describes renames then it should be considered advisory,
and an option to override it should exist because it may be wrong.

Nonetheless, if such feature existed users that are willing to generate
such metadata and review it before it gets merged may get more out of
the rename tracking than can be done automatically today.

Thanks

Michal