Thierry I think that what ben want to say is:
- provide a default
"but I don't want to enforce a specific way of organising the git
repository… "
Stef
PS: I would love to be able to use git for managing Pharo so keep pushing. Now
we cannot allocate more resources to this task but last year I request to inria
some resources for this task (and it was rejected).
>
>
> Le 13/09/2013 17:04, b...@openinworld.com a écrit :
>> Goubier Thierry wrote:
>>>
>>>
>>> Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
>>>> Is anybody using FileTree repositories?
>>>
>>> Which repositories? Dale's github?
>>>
>>>> If so, I'd like to know the pros and cons of using it.
>>>
>>> More complex to use than Smalltalkhub/Squeaksource because it is not
>>> yet integrated in the default image. Some features may not work, but
>>> average MC work under Pharo2.0 works fine with all features of
>>> Filetree (including gitfiletree).
>>>
>>> Easier to use than Smalltalkhub/Squeaksource for authentification.
>>>
>>>> I want to use to version everything with git, but I don't know how it
>>>> keeps git (it is, FileTree files) in sync with MC versions.
>>>
>>> A filetree repository appears as a MC repository in the same way as
>>> another type of MC repository.
>>>
>>> Filetree will require that you do all your version management in the
>>> git repo by hand (i.e. save a version of your package in a filetree
>>> repo, then switch to a console to commit it. If you forget to commit
>>> and save a new version of a package on the filetree repo, you
>>> overwrite the previous version and git will not record it. Filetree by
>>> itself will only show you the state of the HEAD of your git repository).
>>>
>>> If you use gitfiletree (it sits over Filetree), then git commit will
>>> be done for you when saving your package, and the repository browser
>>> will show you all the history of the repository, exactly as if it was
>>> a Smalltalkhub or Squeaksource repository. What will remain to do on
>>> the command line are the git push and whatever management you do on
>>> the repository (merging, branching, even if you can also merge via MC
>>> instead). In short, gitfiletree calls git for you and parse the
>>> results :)
>>>
>>> I'm still wondering about adding more git commands inside the MC GUI
>>> to do more from inside Pharo (like automagically pushing), but I don't
>>> want to enforce a specific way of organising the git repository... and
>>> I'm just trying to get gitfiletree to pass its tests in the pharo3.0
>>> branch of Filetree at the moment.
>>>
>>> Does this answer your questions?
>>>
>>> Thierry
>> > but I don't want to enforce a specific way of organising the git
>> repository
>>
>> I see this extreme altruism :) around the community, and while it is
>> very admirable, I think sometimes its misplaced :). The flip side is
>> that some people (like me) aren't really familiar with git don't know
>> how we might want git organised, or even what the options are.
>> Unfortunately this stalls my motivation to try it out (sorry, weak, I
>> know - but I admit it, and I think its common (or do I just think that
>> to make myself feel better)). Having a concrete implementation of any
>> additional functionality that might make git more transparent "out of
>> the box" would be beneficial for its uptake. As well, without a
>> concrete example, others who might want to implement something like that
>> have to start more from scratch, whereas your concrete example might be
>> 90% of what someone wants and then its only 10% that they need to
>> customize. The reality of human nature is that its easier to criticize
>> to pick out what you don't like, than to create something new. However
>> the hidden benefit of this criticism is that it engages people in
>> discussion and then you hook them into helping develop what they need.
>> So anyway, my short response is, if "you" would benefit from that added
>> functionality then "just do it". :)
>> cheers -ben
>>
>> P.S. I admire what I read about progress with Filtetree and GitFileTree
>> towards using git. For some segments outside the Pharo community that
>> we want to draw in, this is going to be an important consideration.
>
> Hi Ben,
>
> I'm sorry that this doesn't convince you to use git with Pharo :)
>
> So far, I very happy with the functionality gitfiletree has; for a common
> user like me it has been working very nicely for quite some time now :):) It
> has the features I need: allow the introduction of pharo development in any
> pre-existing / mixed language repository; allow me to build in 5 sec a new
> repo for a package; integrate with github; better long history exploration
> than anything else under Pharo.
>
> At the same time, it was a bit of a mock-up, this gitfiletree: just adding
> some automation to a filetree over git repository, and also add some
> motivation for someone else to see what can be done and how, so as to
> eventually reimplement it as a FileSystem / or as a libcgit instead of
> calling git log and git archive :)
>
> It's now a bit of a bench for some future directions of FileTree, such as
> removing the metadata which is provoking conflicts when merging under git, or
> as a new replacement of changesets (but EPICEA is going in another
> interesting direction, so I'm not trying anything there).
>
> And don't worry for my altruism not adding functionalities :) I'm the guy who
> wrote a complete alternative IDE for pharo 2.0, just because I prefer it to
> Nautilus :O
>
> Thierry
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
>
