Re: Storing collection ref (collection ID + ref) in the commit metadata

[Colin Walters <walters verbum org>]

(more thoughts on this)

On Wed, Jun 28, 2017, at 10:53 AM, Colin Walters wrote:
> > Support for multiple refs in the commit metadata is more about the
> > situation where a series of commits belong to two branches. For
> > example, when branching off a version, there might be several commits
> > which are shared between $version_branch and master before they
> > diverge. Is that realistic use case?

Also in Fedora Atomic Host, (may have said this before) we
currently have a "promotion" where the release script takes a
commit from
fedora/26/x86_64/updates/atomic-host   (corresponding to packages in bodhi)
and promotes to:
fedora/26/x86_64/atomic-host  (a ~two week cadence commit)

And so indeed we currently have a case where that single commit
needs to be bound to those two refs.  Which is why I'd certainly
be happy with having support for binding a single commit to multiple
refs.

However, as I mentioned I also want to change this to stop doing commit promotion
and instead do content promotion, like flatpak's `build-commit-from`
and do-release-tags.  Once we do that, we'd be back to one ref per
commit.

But all of this is fundamentally different from a build system that actually
does "branching from" rather than "promotion to"; which is what you're
talking about right?  I'm happy to try to accommodate that (particularly
if someone pipes up saying they do it) but in the big picture it feels
like a bad idea to me, since you introduce https://en.wikipedia.org/wiki/Hysteresis
into your build system.  Put another way: flatpak-builder, rpm-ostree, and
gnome-continuous all have *caches* but if you e.g. change the input manifest to
drop something out, it goes away in the next commit.  For rpm-ostree in particular,
we always do a dependency resolution as if we're doing a fresh install.  What
happened to be in the previous ostree commit is irrelevant.