[NOTES 07/11] Change-ID Header in Git

Topic: Change-ID Header in Git
Leader: Philip Metzger

* How do we store the Change-ID? Store it in a header? Some auxiliary metadata
	store?
* Happens to work in a header for GitHub because they survive rebases since
	GitHub uses replay, not all forges do this.
* Want a standard interoperable way to associate Change-IDs with commits.
* Storage discussion has largely been covered.
* Taylor: what's less clear to me is the semantics of when we keep Change-IDs
	across operations, when we assign new ones.
	 * Cherry-picking equivalent assign a new Change-ID
	 * Almost everything else retains that Change-ID
* Taylor: we need to agree on the storage, but not necessarily on the semantics
	of when we keep versus assign new Change-IDs.
* Caleb: Assigning a new Change-ID when cherry-picking is interesting, since we
	(GitButler) retain those.
* Philip: Gerrit does the same thing, but JJ does something differently. Their
	approach was to have an optional header that describes the “origin” (in some
	sense) of the commit.
* Caleb: I wonder if the semantics are important if we are trying to use these
	in the same sandbox?
	 * Taylor: we need to understand and agree on them when we are working on the
		 same repository (regardless of using the same tool), but not in general at
		 the tool level.
* What's the next step?
* Martin: experiment with it, see if we like the semantics. Don't want to
	emphasize the divergence table.
* Taylor: do we need a version associated with the change-id? Philip: no, we
	treat it as an opaque identifier, versioning not necessary.
* Elijah: given that multiple players want this and have agreed on a common way
	to represent it, maybe we'll have a more productive discussion on it in a year
	after they've experienced working with that header for a year
* Jonathan: does it matter what forges do with automatic squash/rebase?
	 * Philip: for JJ we don't want to use that information, but we're just
		 another Git client in the ecosystem, so that's just our perspective.
* Martin: Should there be agreement on the semantics?
	 * Elijah: depends on the usage.
* Elijah: semantics get fuzzy because of splitting and merging, so not clear
	what to do there. We either need to clarify it, but probably not here.