On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <[email protected]> wrote:
> Hi,
>
> I’ve been using git for all my projects since more than one year now, and 
> frankly I found it really good… and the pull request mechanism is unbeatable.
> Now, what I do believe is that we need to improve a couple of things:
>
> 1) filtree format is not good while working on teams (which is the power of 
> git, after all). Merging is a pain and the merge driver provided by Thierry 
> is just a patch, not a real alternative.
> 2) double commit is annoying.
>
> We have a decent solution for (2), gitfiletree but is not working fine in 
> windows (and that’s mandatory). I would like a community push here to make it 
> work fine.
> Once is working, I would like to replace the OSProcess usage with actual 
> libgit2. As far as I understand, this is already possible but we hadn’t 
> commit time to make it possible (and I would put it as a secondary goal: 
> first make it work with what we have, then use the library).

Would moving to libgit2 bypass the problem with stdio?

> Now the filetree format has problems merging because it stores some metadata 
> that we do not really need. The origin of this is the fact that is using git 
> as “just another interchangeable repository for monticello”. IMHO while this 
> was desirable for start, is not a good solution now. We do not need that 
> information at all.
> I worked in a replacement for filetree and as a file format it works fine… is 
> just a variation who does not stores the not-needed information and relies on 
> STON to manage the one we actually need.

I have a vague recollection that the problem was a particular file
where data changed each commit and having the idea that this might be
solved by: each commit writing metadata to a different file e.g.
NNNN.metadata, and Monticello knows to pick up the highest numbered
metadata.


> After, we can build the actual tools we need. But with that working we will 
> see a lot clearer what we actually need to do :)
>
> So I would do a “call for pushing” and ask community to spend some time 
> making it work properly.
>
> cheers,
> Esteban
>
>
>> On 27 Sep 2015, at 13:43, stepharo <[email protected]> wrote:
>>
>> Alex do you know git?
>> Because to me git is **really** complex. I do not talk about add push commit 
>> but rebase remote....

Git is very flexible which implies complexity for newcomers to it.
What is required on top of git is a "well defined" workflow.    I see
sometimes on this mail-list that people design their tools for
flexibility since they don't want to *impose* a workflow on people,
which is a commendable philosophy, but slows adoption by newcomers.
It may be useful to define "this is *the* way its done here" , with
the standard proviso that there may be missteps that need to be tuned.

cheers -ben


>> Did you try to use sourcetree (the UI for git) to understand what I mean?
>> So we cannot use git simply we have to propose a much nicer model on top of 
>> this assembly.
>>
>> Now you can systematicall save your code with monticello and automatically 
>> publish it to git.
>> Esteban has a script for doing that.
>>
>> Stef
>>
>>> … Pharo may be within the 30 most popular languages on Earth.
>>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>>>
>>> I wish we had a nice Git integration.
>>>
>>> Alexandre
>>
>>
>
>

Reply via email to