[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] raisin: Some git-checkout improvements
On Wed, 22 Apr 2015, George Dunlap wrote: > On 04/22/2015 03:54 PM, Stefano Stabellini wrote: > > On Wed, 22 Apr 2015, George Dunlap wrote: > >> On 04/22/2015 03:11 PM, Stefano Stabellini wrote: > >>> On Tue, 21 Apr 2015, George Dunlap wrote: > >>>> 1. Switch local variables to lower-case and declare them local. > >>> > >>> This is good. > >>> > >>> > >>>> 2. Cloning git trees from remote repos is often a very long operation. > >>>> Allow the user to specify a faster git cache as a prefix. > >>>> > >>>> 3. At the moment you can either check out a specific changeset or > >>>> "master", but you can't check out a different branch, because git > >>>> doesn't always look in origin/ for the branch. If the initial git > >>>> checkout $tag fails, try checking out origin/$tag before giving up. > >>> > >>> I am in two minds about this, because it is still possible for the user > >>> to simply: > >>> > >>> LIBVIRT_REVISION="origin/blah" > >> > >> Then we should have all the revisions point to "origin/master" for > >> consistency. > > > > That is true. I think it is probably simpler that way. > > > > > >> In any case, it requires the user to know the default remote repository > >> name. > > > > Right, but that is always origin, isn't it? In fact you would hardcode > > it in the script with your change below: > > > > + $GIT checkout -b dummy $tag \ > > + || $GIT checkout -b dummy origin/$tag > > Sure, but that's an internal implementation detail. We just cloned it, > so we should know what the remote branch name is. We don't necessarily > want the user to rely on that, in case we want to change the > implementation somehow. > > But if you don't mind changing the default to "origin/master", I won't > argue too much. I think the chances of us changing away from "origin" > are *very* slim. :-) OK, good > >> A brief scan of the git man page, combined with a brief survey of > >> Google, didn't turn up anything... > > > > All right. You might just want to add few more words in the comment on > > defconfig, or maybe a pointer to an url that explains what a git proxy > > is. > > I would have done it this time if I'd known much about the git proxy. > Unfortunately it doesn't look like a proper project at the moment; it > seems to be mainly available from a debian package called > "chiark-scripts" that IanJ maintains. > > We shouldn't rely on a private program not publicly available; so either > we should try to make git-cache-proxy a public project, or I should find > another suitable proxy to point people to. (Or just give up on it for now.) I agree _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |