Re: Feature request: provide a persistent IDs on a commit

From: Hilco Wijbenga <hilco.wijbenga@gmail.com>
Date: Jul 21, 2022, 18:58 UTC
Message-ID: <CAE1pOi1pS76iXU8j=A54wPGHC7qofxrPDAO4uyy0d6yMxeQwvw@mail.gmail.com>
In-Reply-To: <87a692e8vj.fsf@vps.thesusis.net>

On Thu, Jul 21, 2022 at 9:39 AM Phillip Susi <phill@thesusis.net> wrote:

Show 9 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > 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.