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

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.

Thanks

Michal

Rebase is typically reserved only to modify commits which are not yet
"permanent". Once a commit starts being referenced by many others it
becomes more and more difficult to rebase it. Any rebase effectively
creates a new commit.

There are multiple threads discussing renames and handling them in git
in the past which are worth re-reading, including at least

https://public-inbox.org/git/Pine.LNX.4.58.0504141102430.7211@ppc970.osdl.org/

A fuller analysis here too:
https://public-inbox.org/git/Pine.LNX.4.64.0510221251330.10477@g5.osdl.org/

As mentioned above in this thread, depending on what context you are
using, a change to a commit could be many to many: i.e. a commit which
splits into 2, or 3 commits merging into one, or 3 commits splitting
apart and then becoming 2 commits. When that happens, what "change id"
do you use for each commit?