On Mon, 25 Jul 2022, Ani Sinha wrote:
> > > On Sat, 16 Jul 2022, Michael S. Tsirkin wrote: > > > On Sat, Jul 16, 2022 at 12:06:00PM +0530, Ani Sinha wrote: > > > > > > > > > On Fri, Jul 15, 2022 at 11:20 Michael S. Tsirkin <m...@redhat.com> wrote: > > > > > > On Fri, Jul 15, 2022 at 09:47:27AM +0530, Ani Sinha wrote: > > > > > Instead of all this mess, can't we just spawn e.g. "git clone > > > --depth > > > 1"? > > > > > And if the directory exists I would fetch and checkout. > > > > > > > > There are two reasons I can think of why I do not like this idea: > > > > > > > > (a) a git clone of a whole directory would download all versions of > > > the > > > > binary whereas we want only a specific version. > > > > > > You mention shallow clone yourself, and I used --depth 1 above. > > > > > > > Downloading a single file > > > > by shallow cloning or creating a git archive is overkill IMHO when > > > a wget > > > > style retrieval works just fine. > > > > > > However, it does not provide for versioning, tagging etc so you have > > > to implement your own schema. > > > > > > > > > Hmm I’m not sure if we need all that. Bits has its own versioning > > > mechanism and > > > I think all we need to do is maintain the same versioning logic and > > > maintain > > > binaries of different versions. Do we really need the power of > > > git/version > > > control here? Dunno. > > > > Well we need some schema. Given we are not using official bits releases > > I don't think we can reuse theirs. > > OK fine. Lets figuire out how to push bits somewhere in git.qemu.org and > the binaries in some other repo first. Everything else hinges on that. We > can fix the rest of the bits later incrementally. DanPB, any thoughts on putting bits on git.qemu.org or where and how to keep the binaries?
