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

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

On Sat, Jul 23, 2022 at 10:23 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Sat, Jul 23, 2022 at 12:44 AM Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Fri, Jul 22, 2022 at 03:46:22PM -0700, Jacob Keller wrote:
> > > 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:
> [...]
> > > > > 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.
> > > >
> > >
> > > 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?
> >
> > Same as commit message and any trailers you might have - they are
> > preserved, concatenated
>
> Exactly how are they concatenated?  Is that a user operation, or
> something a Git command does automatically?  Which commands and which
> circumstances?  If users do it, what's the UI for them to discover
> what the fields are, for them to discover whether such a thing might
> be needed or beneficial, and the UI for them to change these fields?
> This sounds like a massive UX/UI issue that I don't have a clue how to
> tackle (assuming I wanted to).
>
> > and can be regenerated.
>
> "can be".  But generally won't be even when it should be, right?
>
> Committer name/email/date basically don't even exist as far as many
> Git users are concerned.  They aren't shown in the default log output
> (which greatly saddens me), and even after attempting to educate users
> for well over a decade now, I still routinely find developers who are
> surprised that these things exist.
>
> Given that committer name/email/date aren't shown with --pretty=full
> but with the lame option name --pretty=fuller, I can't see why it'd
> make any sense to show Change-Ids in the log output by default.
>
> But if it's not shown -- and by default -- then it doesn't exist for
> many users.  And if it doesn't exist, users aren't going to fix it
> when they need to.
>
> (Even if it were shown by default, it's not clear to me that users
> would know when to fix it, or how to fix it, or even care to fix it
> and instead view it as a pedantic requirement being foisted on them.)
>
> I think the "many-to-many issue" others have raised in this thread is
> an important, big, and thorny problem.  I think it has the potential
> to be a minefield of UX and a steady stream of bug reports.  And
> seeing proponents of Change-Id just dismissing the issue makes me all
> the more suspicious of the proposal in the first place.

I do think there is some value in having a sort of generic id like
change-id, but I do think we want to be careful about how exactly we
handle it.

As you say, if we hide it then users may not be aware of it, and if we
make it visible users who don't care may be annoyed. I don't think we
can fully automate it because of the nature of combining changes and
splitting changes require humans to decide which change keeps which
ID. Its not even clear when rebasing whether a split is going to
happen. A combine operation is easier to detect in rebase
(fixup/squash), but determining which id to keep is not. Would we even
want to have support for "this commit merges two and is now one, but
we keep both IDs because it really is both commits"? That gets messy
pretty fast.

Users such as gerrit already simply use the trailer with Change-id and
manage to make it work by enforcing some constraints and assuming
users will know what to do (because otherwise they fail to interact
with gerrit servers).

For cases where it helps, I think its very valuable. Being able to
track revisions of a series or a patch is super useful. Getting
external tooling like public-inbox, patchworks, etc to use this would
also be useful. But I think we would want to sort out the situation a
bit for how and when are they generated, when are they
replaced/re-generated, how this interacts with mailing etc.

Should rebase just always regenerate? that loses a lot of value. I
guess squashing could offer users a choice of which to keep? Fixup
would always keep the same one. And otherwise it becomes up to users
to know when they need to copy from an old commit or refresh an
existing commit... Thats pretty much what gerrit does these days, if a
commit doesn't have the trailer it gets added, and if it does, its up
to the user to know when to remove it or regenerate it... Since its a
commit message trailer it gets sent implicitly through the mailing
list unless removed.