Re: [Xen-devel] [PATCH] raisin: Some git-checkout improvements

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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. :-)

>> 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.)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel