[Pharo-users] Pharo + git workflow

Thierry Goubier thierry.goubier at gmail.com
Mon Jan 25 15:36:51 EST 2016

Hi Norbert,

Le 25/01/2016 21:17, Norbert Hartl a écrit :
> Hi Thierry,
>> Am 25.01.2016 um 20:45 schrieb Thierry Goubier
>> <thierry.goubier at gmail.com <mailto:thierry.goubier at gmail.com>>:
>> Hi Norbert,
>> Le 25/01/2016 20:01, Norbert Hartl a écrit :
>>>> Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert at hartl.name
>>>> <mailto:norbert at hartl.name>>:
>>>> I'm eager to try a new project with some git repositories. But to
>>>> be honest I don't really get it. Searching the web there is lots to
>>>> find but nothing actual.
>>>> I don't understand if it is ok to use a ConfigurationOf or if it
>>>> only works with a BaselineOf. And how do you specify the repository
>>>> in a ConfigurationOf in order to be able to work locally as well as
>>>> having jenkins pull everything automatically? Same goes for
>>>> dependent projects.
>>>> Are there any insights to this or pointers to an up-to-date
>>>> documentation?
>>> My own insights so far when using git:
>>> - I need to use BaselineOf instead of ConfigurationOf. Thus you
>>> cannot use Versionner anymore
>> You can use ConfigurationOf. BaselineOf is only there to help.
> Ok, good to know.
>>> - I need to load metacello-work from github in order to use
>>> bitbucket:// repositories
>> This should be an issue for Pharo.
>>> - Metacello downloads a zip file from the repository to install code.
>>> I have no glue how I can download things locally in order to work on
>>> the code
>> Metacello github:// and bitbucket:// urls are only for read-only access
>> to the packages (distribution).
>> Metacello install the contents of the zip into a path composed of
>> github-cache (or bitbucket-cache I guess), the repository name, person
>> name, commit id or version as a filetree repository. You can add that
>> repository as a filetree repository inside Monticello if you want. But
>> it is read-only.
> That is ok if you produce a deployment artefact, e.g. with jenkins. But
> there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
>> Download locally is done by either a git clone on the command line or by
>> a GitFileTree remote repository addition.
>>> - Specifying a path to access a sub-directory of the repository seems
>>> not to be possible
>> It is: url format is
>> [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
> It works without sub-directory. With it throws an error
> 'Git error: Cloning into ''st''...
> conq: invalid command syntax.
> fatal: Could not read from remote repository.
> Please make sure you have the correct access rights
> and the repository exists.

Oh, I see. You're using the stable version of GitFileTree in Pharo4, 
isn't it?

I haven't pushed the changes for the url syntax in that version. So the 
old syntax becomes:


My problem is that the new url syntax is in the same package as the 
metadata-less mode of GitFileTree, and that mode supposes a fix to 
FileTree (a single method!). Maybe I'll switch the Pharo4 development 
version to not create metadata-less repositories.

>> It is also allways possible to reopen a filetree or a gitfiletree repo
>> on a sub-directory of the main repository... this is how FileTree itself
>> is tested for integration.
>>> - I don't know where to specify credentials because I have a private
>>> repo on bitbucket
>> If you have a ssh key, then GitFileTree will pick it up for you.
> Yes, that is my preferred way, too.

Well, that one really had to work :)

>>> My conclusion is that if you don't want to use versionner and you
>>> have public projects on github using that stuff might seem feasible.
>>> If any of those is different it won't work. Right?
>> No, it works and has been working for git access to private
>> repositories, bitbucket included, for years... at least on Linux ;)
> Ok, thanks, if the sub-directory stuff would work it would be ok to jump
> in. Maybe there is a way to tweak the url in the baseline. It would
> remove the need to install gitfiletree in a deployment artefact. We'll see.

In a deployment artefact, then it becomes a bit different because your 
repo is then public.

What I did for a Pharo4 deployment was to write a context dependent 
Makefile which uses filetree if I'm dealing with an archive of my 
artefact, and gitfiletree if it is build from a development repo.

> Thanks again,

You're welcome. I'll update GitFileTree for Pharo4 soon and recommend 
that you use the development version.


> Norbert

More information about the Pharo-users mailing list