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

[Jacob Keller <jacob.keller@gmail.com>]

On Fri, Jul 22, 2022 at 1:42 PM Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Fri, Jul 22, 2022 at 09:08:56PM +0100, Philip Oakley wrote:
> > On 21/07/2022 19:58, Hilco Wijbenga wrote:
> > > On Thu, Jul 21, 2022 at 9:39 AM Phillip Susi <phill@thesusis.net> wrote:
> > >> Ę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.
> >
> > 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?