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

> 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?