sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches
- From: Javier Vasquez <j.e.vasquez.v AT gmail.com>
- To: Jaka Kranjc <smgl AT lynxlynx.info>
- Cc: "sm, discuss" <sm-discuss AT lists.ibiblio.org>
- Subject: Re: [SM-Discuss] [sm-discuss] about grimoires from git branches
- Date: Sat, 18 Jan 2014 12:50:50 -0600
On Sat, Jan 18, 2014 at 12:35 PM, Javier Vasquez
<j.e.vasquez.v AT gmail.com> wrote:
> On Sat, Jan 18, 2014 at 11:44 AM, Jaka Kranjc <smgl AT lynxlynx.info> wrote:
>> On Saturday 18 of January 2014 11:14:58 Javier Vasquez wrote:
>>> ...
>>>
>>> scribe add <grimoire_name> from
>>> git_http://scm.sourcemage.org/smgl/grimoire.git:<local_branch_name>:<orig_br
>>> anch_name>
>>>
>>> It does work OK on development version.
>>>
>>> However updates take way longer that I would expect. It looks to me
>>> (I haven't seen a verbose output) that instead of updating through
>>> "git pull", sorcery is cloning again the whole stuff. Am I right?
>
>>
>> Hey,
>>
>> from a cursory look, why do you expect the second parameter to be
>> local_branch_name?
>
> I supposed that's the way it's working. But I was mistaken. By looking at:
>
> /var/lib/sorcery/modules/url_handlers/url_git_http
>
> I just realized that it's the name of the directory where the local
> repo resides:
>
> ++++++++++
> ## @Global URL
> ## @Global GIT_ROOT
> ## @Global GIT_DIRECTORY
> ## @Global GIT_TAG
> ##
> #---------------------------------------------------------------------
> function url_git_http_crack() {
>
> URL=`url_strip_prefix "$1" git_http`
> GIT_ROOT=`echo $URL | sed "s#\(^[^/]*[^:]*\):.*#\1#"`
> GIT_ROOT=http://$GIT_ROOT
> local GIT_DIRECTORY_TAG=`echo $URL | sed "s#^[^/]*[^:]*\(.*\)#\1#"`
> GIT_DIRECTORY=`echo $GIT_DIRECTORY_TAG | cut -d : -f2`
> local GIT_TAGNAME=`echo $GIT_DIRECTORY_TAG | cut -d : -f3`
> GIT_TAG=${GIT_TAGNAME:=master}
>
> }
> ++++++++++
>
> Not easy to read though... The rule is that the directory name
> matches the grimoire name given, otherwise I don't know if things
> would work though, :-)
>
> So thanks to clarify I was wrong, but any ways, I always was using the
> same grimoire name as 2nd argument, so that was OK on my side at
> least, :-)
>
>>
>> Anyway, it just has to stay the same and present. Only then
>> we don't reinitialise it.
>
> I didn't understand this comment, :-( Did you mean that you wouldn't
> expect a git repo branch used as grimoire to ever get updated, and if
> it does, then it gets cloned all over again?
Actually by looking at how the grimoire ends up:
% git branch -a
* master
It doesn't look right to me, given, there's no single remote branch
reported. That way there's no opportunity to perform "git pull" even
manually.
Is that the way all git repos are treated? Included those used in the spells?
It seems weird to me we have to clone all over again the repos when
updating, :-(
For the grimoire itself, it seems cloning manually and checking out
the branch manually, and then performing manual git pulls, is a better
option that the automated sorcery way.
Am I misinterpreting something?
Thanks,
--
Javier.
-
[SM-Discuss] [sm-discuss] about grimoires from git branches,
Javier Vasquez, 01/18/2014
-
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches,
Jaka Kranjc, 01/18/2014
-
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches,
Javier Vasquez, 01/18/2014
-
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches,
Javier Vasquez, 01/18/2014
-
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches,
Jaka Kranjc, 01/18/2014
- Re: [SM-Discuss] [sm-discuss] about grimoires from git branches, Javier Vasquez, 01/18/2014
-
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches,
Jaka Kranjc, 01/18/2014
-
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches,
Javier Vasquez, 01/18/2014
-
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches,
Javier Vasquez, 01/18/2014
-
Re: [SM-Discuss] [sm-discuss] about grimoires from git branches,
Jaka Kranjc, 01/18/2014
Archive powered by MHonArc 2.6.24.