On Wed, 2017-06-28 at 11:07 -0400, Colin Walters wrote:
(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.
OK.
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/w iki/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.
Unless someone pipes up, let’s avoid explicitly supporting using refs for ‘branching from’ then. In light of that, having a static list of refs in the commit metadata, and not supporting dropping them seems fine to me. If people want support for that in future, we could always, for example, add some detached metadata to the commit which indicates that one of the refs has been dropped. Or create a new commit pointing to the same content tree which has different metadata (less one ref). Philip
Attachment:
signature.asc
Description: This is a digitally signed message part