Le 02/12/2014 20:41, Yuriy Tymchuk a écrit :
On 02 Dec 2014, at 19:03, Thierry Goubier
<[email protected]> wrote:
Le 02/12/2014 17:13, Yuriy Tymchuk a écrit :
Hi Luc,
most of these problems are solved by gitfiletree by Goubier
Thierry. It automatically commits the thing that you commit with
Monticello, it allows you to push, and it shows you the history
(sometimes a bit screwed, but good enough). ConfigurationOf works
with GitHub projects, but I think there is also something in a
new Metacello that I don’t know about.
If you find a strange history, can you share? It seems it happens,
but I'm never sure. It handles fairly complicated cases (like the
FileTree repository where, in some commits, you can't load the
packages with filetree because they are broken: merge conflicts
usually).
Big con is that you essentially communicate with git through
Monticello. And to doing advanced stuff, like a lot of
branching, pull requests and so on, gives an impression that you
are always hacking something.
I think this is the git philosophy anyway. You need to go on
expensive, entreprise versionning systems (ClearCase?) to have a
very powerfull, yet still handholding system. Git is a hacker's
tool. And git users are supposed (encouraged?) to hack it.
My problem is not in git, it’s in Monticello. I’m used to be able to
commit exactly what I want even if I’ve made more changes, I’m used
to make branches for each new feature and then merge it back… But I
always have two versioning going on. I do things in git, and then I
do things in monticello. Another problem is a real lack of features.
Yes. I can understand that. It's very hard, in truth, to make that
integration work. I'm cheating with Monticello in many places, just to
reach that goal.
Imagine if you could see a method blame from inside Pharo.
That one would be real easy, in fact :)
You just have to touch the GUI in Nautilus and add a command to
GitFileTree (five or ten lines, no more).
AltBrowser has one additional gui(s) which is triggered with gitfiletree
support: a method version browser which is just like the normal one,
except that it queries git for method versions in addition to the ones
kept in the changes.
Adding git blame access would be done in the same way.
If you want to really work with git, you want to be able to have
only git versions of your code, stage and commit certain
changes, communicate with remote repos, and if something goes
wrong talk to command line and deal with file-based pharo
representation. But instead of this you have one more screen of
Monticello + nasty metadata which complicates merging.
You need to use the merge driver for that, really. Ok, it requires
a lot more polish than it has, but this is a larger, Pharo wide
effort we need to plan for. The GitFileTree-MergeDriver was really
a proof-of-concept which worked surprisingly well for the time I
spent on it.
Yes, but my main point is what when I merge, I don’t care about
monticello data… I already have a git version, why do I have to care
about the ancestor of monticello version that became different
because of cherrypicking.
Hum. You'll need to give me an example because I don't know enough git
to understand what you're saying.
Do you mean that, if you merge in git, when reloaded in Pharo, it
doesn't show you the right history? Or do you say that merging with
Monticello doesn't appear correctly in git?
Again, I’m not complaining. I’m very glad that we have what we have
now. It’s just that I don’t agree that git support is ready to be
used by everyone. Because with git in general I’m 10x more efficient
than with git in Pharo. And with git in pharo it’s the same as with
monticello, I just trade one problems for another ones.
Well, I guess that in both FileTree and GitFileTree visions, we went
into close integration with the existing Monticello, with all the
limitations inherent to that approach.
Now, the question is how we make a better use of what we have access to.
Thierry
