On Tue, 2018-09-04 at 09:55 +0200, Erik Skultety wrote:
> Initially, I wanted to point out that "revision" is probably not the best name
[...]
I was thinking yesterday that perhaps it would be better to
use '-g GITREVISION' here instead, to leave '-r' available for
future extensions, eg. when/if I get around to adding support
for dependencies between projects that could be used to mean
'recursive', as in: build this one project and also all those
that depend on it, the same way CentOS CI does it. Does that
sound reasonable?
[...]
> > def _action_build(self, hosts, projects, revision):
> > + if revision is None:
> > + raise Error("Missing git revision")
>
> see above...as I said, I still don't see a reason for requiring ^this, if there
> truly is a compelling reason to keep it, then I'd suggest changing the default
> remote name to "origin" from "upstream", because it feels more natural and
> intuitive to me. Even though you document this in the README and I understand
> the reasoning - you can name your origin whatever you want + you can clone your
> fork and then add an upstream remote, but I wouldn't expect that to be very
> common practice.
Let's just use "default", that one doesn't have any charged
meaning in the git world and it's pretty accurate, too.
I'll also make the whole thing optional. I still have a slightly
uncomfortable feeling about it, though I can't quite put it to
words... Plus unlike with libvirt going one way or another won't
quite lock us into that decision forever, so I'm more willing to
just try stuff ;)
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
