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

[Colin Walters <walters verbum org>]

On Tue, Jun 27, 2017, at 09:42 AM, Philip Withnall wrote:
> That all makes sense. Are you happy with the fact that putting refs in
> the commit metadata basically makes `ostree refs --delete` worthless,
> since those ref references in the commit metadata can never be deleted?
> I guess we could sidestep that by defining the commit metadata as “the
> list of refs the commit belonged to *when it was written*” which makes
> the potential lack of freshness obvious.

I don't understand the problem here; if you delete the ref, the corresponding
commit should be pruned (at the next repo prune) since we're not talking
about having any other refs to it, right?  (OK, more on this below) 

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

I guess this is where to me the ostree-as-git analogy breaks down a lot,
since at least the way I intended it to be used, you don't ever fork a branch in the
git sense.  Rather, your build system always regenerates ostree commits
from input.  They just (this part is like git) happen to share storage.

Taking the Fedora Atomic Host example, we have
fedora/26/x86_64/atomic-host
fedora/27/x86_64/atomic-host

And certainly at a *source code* level, 26 was a point-in-time fork of 27...
but that relationship isn't expressed in the ostree side at all, we just
rerun rpm-ostree and accumulate history there.

Now certainly we *could* try to have the first 27 commit actually inherit from
the last 26.  Conceptually it feels nice, but OTOH there are problems because
we actually want history on 27 while it's being developed...so we'd need to
have some special process when things become GA?

Is there anyone who maintains a build system that actually uses
the final ostree *contents* as input when generating new content?  (As
opposed to reassembling from artifacts, where those artifacts might actually
be stored in ostree as well, like gnome-continuous does)