> On 28 Sep 2015, at 04:27, Ben Coman <[email protected]> wrote: > > 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?
Yes. We call out to libgit2 through NativeBoost. > >> 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 >>> >>> >> >> >
