Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer

[Junio C Hamano <gitster@pobox.com>]

"Theodore Ts'o" <tytso@mit.edu> writes:

> ...  This *might* get better if we shove it into a
> git commit header, although if you give people tools to edit the
> Change-Id as part of a "git commit --amend", some tools might end up
> changing the Change-Id in random ways again.

Thanks for pointing these out.  I agree with the above, and it is
one of the reasons why I doubt that it would be a win to have this
information in the header part.

> ... So if I need to cut and paste a
> Commit-Id, I might as well cut and paste the one-line commit summary,
> and do a "git log --grep" search based on that.  But if the Commit-Id
> is indexed, then maybe it might be more useful?  I dunno....

If the information becomes useful enough, we will definitely start
adding index for it, just like we only have "parent" header field in
commit objects to represent transitive NxM parent-child relationship
to start with but have in the form of reachability bitmaps an index
of which commit can or cannot reach which other commits.  With squash
and split you outlined above (omitted from my quote), it is likely
that you'd want similar transitive NxM predecessor-successor relationship
among a family of commits that represents patchset evolution, and an
index constructed with a similar principle should work well.

> Well, see above about some possible semantics.  I'm *still* not
> convinced even with the better-defined semantics it's worth storing
> the extra baggage in the commit header.  But that's more of a
> value/philosophical question, much like how we "could" store explicit
> file rename information in the git commit, but in the very early days
> of the git design history, although BitKeeper did track file names,
> Linus consciously decided to go down a much simpler path.  So that's
> really more of a SMTP vs X.400 preference of simplicity versus
> complexity in the protocol versus implementation...

It is not "simpler is more manageable".

The early days' design decision, which still lives to this day, was
a bit stronger than that.  As can be read from [*1*] (which by the
way I consider one of the most important message regarding the
design in early days of Git), the design started from "recording
renames is pointless".

Thanks.


[Reference]

*1* https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/