On Wed, 2017-06-28 at 10:53 -0400, Colin Walters wrote:
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)
You’re right about the case for deleting the only ref pointing to a commit. For the case where multiple refs point to a commit and one of them is deleted, there’s still a problem. But I’m happy for that to be addressed by considering the refs list to be for when the commit was written, rather than fresh.
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?
Sure, that makes sense. So there are actually very few situations where we’d expect a given commit to be on multiple branches, right?
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)
Not us. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part