[ruby-core:21219] Re: Happy new year and... moving Ruby development to Git?

On Thu, Jan 8, 2009 at 12:07 PM, Florian Gilcher <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Jan 7, 2009, at 5:23 PM, Giuseppe Bilotta wrote:
>
>> On Mon, Jan 5, 2009 at 6:45 PM, Florian Gilcher <[e-mail]>
>> wrote:
>>>
>>> On Jan 5, 2009, at 5:29 PM, Giuseppe Bilotta wrote:
>>>
>>> I'm on the "i don't want to think to much about it" or "lazy bastard"
>>> side.
>>
>> Me too.
>>
>>> For example, one of my main reasons for darcs is it's nice cherry-picking
>>> interface that is the _default_ way of handling it. Sure, i could use git
>>> cherry-pick and friends, but Darcs gives me the collection of features I
>>> really like at my fingertips.
>>
>> Out of curiosity, what's so special about darcs cherry-picking interface?
>>
>
> Nothing really special, just that it flows nicely and is the default way of
> interaction. So you don't have to decide to cherry-pick, you have to decide
> _not_ to cherry-pick. It's not "advanced usage". If it was, I wouldn't use
> it (see the "lazy bastard" ;) ).

As I said, I haven't used darcs, but it being the default way of
interaction means what? That the most documented function to transfer
patches is cherry-pick instead of (semi)automatic merge?

>>> Also, I tend not to play with branches too much, but only push the
>>> patches I
>>> really want back to upstream/trunk. Thats the default way in darcs.
>>
>> The default in darcs is that you have to choose which commits to push
>> upstream everytime you push? And that's a plus? 8-D
>
> It is. Thats their way of doing "quick branches". Say, you somehow developed
> two independent features in parallel on the same branch, you can then opt
> not to include one of them on the upstream. As long as they are independent,
> you are totally allowed to do that.
>
> It also forces you to somehow think about your patches again. So the typical
> problem with "oh ****, I accidentally included a patch I didn't want to
> push" vanishes.

That makes pushing more work, so I suspect you're not so lazy really ;-)

>>> Sure, I could push git into my workflow, but that would mean I would have
>>> to
>>> costumize git everytime I change computers. It does a lot, but i only
>>> need
>>> half of it and it always takes me time to figure out which half I wanted
>>> to
>>> use.
>>
>> Why would you need to customize git? Having a different workflow with
>> it doesn't mean having to change git parameters, it just means using
>> it in a different way.
>
> Well, pushing some features into view more prominently, like having an alias
> for "git cherry-pick" and so on. In my experience, git has a pretty equal
> distribution for all workflows. That means that my preferred one doesn't
> really stand in the back, but it's also not up front. I am a fan of
> specialized software. So I want one where my workflow stands in front ;).
> So git doesn't fit my needs, darcs does. No offense.

None taken. It's not like git is a religion for me ;-) I don't quite
see the point of having an alias for a command, unless you mean that
you would prefer a shorter form (git cp instead of git cherry-pick)
... aliases make sense for abstruse subcommands, not for commands in
plain view.

Maybe what would be nice to have is a "git for darcs users"
intro/tutorial that summarizes the git commans equivalent to the darcs
commands tipically used in the darcs workflow?

> But in general, the darcs CLI is very though out and infomative. Thats what
> i like about it.

I'm sure the git developers wouldn't mind a couple of patches to bring
darcs on part with darcs in terms of usability. Also, what version of
git do you have experience with? I recently switched to 1.6 which is
even better than 1.5 which (as I'm told) is light years ahead of 1.4,
in terms of UI.

>>> Also, if you allow both workflows, which link will you put on your
>>> website?
>>> ;)
>>
>> That's definitely up to whoever maintains the website 8-D
>>
>
> So, that means that an interested committer has to adapt that.

Assuming ruby WILL switch to git, I'm pretty sure that a contribution
to that patch describing the darcs-style workflow would be appreciated

>>> As I said before: your mileage may vary. I don't like git that much and I
>>> also have a problem with hypes. So I would tend to wait until the
>>> "revolution" is over.
>>> But I support the democratic process ;).
>>
>> Honestly, I don't see this whole "hype" thing about git.
>>
>> If anything, I see a lot of FUD being spread about it, like for
>> example its being extreeeeeemely complex and unfriendly and with an
>> unfamiliar interface, which is something totally opposite to my
>> experience: I didn't find it less friendly or less familiar than, say
>> mercurial (of course there's the clear distinction between committing
>> and pushing, but that's shared by all distributed vcs so it's only
>> unfamiliar to people used to working with centralized vcs only); in
>> fact, I found myself more comfortable with it than with hg.
>
> I didn't say that its extremly complex or explicitly unfriendly.

It wasn't directed at you, but a general remark about some comments
I've been reading in this list and elsewhere.

> I have a
> lot of stuff that I actually like about git (the vast collection of
> transports to other upstreams, for example). But I also have the impression
> that user friendlyness is not one of the gits main goals (which -
> considering the type of programmer it was written for, is not very
> surprising).

As I mentioned, user friendlyness is being worked on, and proceeds
very fast, especially since Linus isn't the lead developer anymore
;-).

If you happen to use git for some projects, I recommend you to switch
to 1.6+ as soon as possible, and if you have any additional
suggestions about how it could be even more user friendly, asking on
the git mailing list and/or the #git channel on freenode is likely to
gather some attention.

> I also know that there is some backlash happening at the moment, at least in
> the set of people I often interact with. A not so small number of people I
> know jumped on the git-wagon and moved back. Thats a typical sign of a hype.

That would lead me to think that those people switched to git without
taking the time to learn to use the tool properly, but that may just
be my impression ;-)

> I don't want to argue that git is bad. I just don't see it as the pinnacle
> of VCS evolution as some people try to sell it.[1] My example with darcs was
> to prove a point: the git glove doesn't fit for everyone. The SVN glove
> doesn't, as well.[2] Same goes for hg and bzr.

Hm. As far as hg goes, and from my experience, I can't think of
anything that hg offers that git doesn't, both in terms of features
and in terms of UI, so I wouldn't be so sure. I can't talk about brz
(like I can't talk about darcs) because I have never used them. SVN
has the big deficit of not being distributed, which is an essential
point IMHO.

> Another word to the discussion. Switching to git doesn't fix the biggest
> problems in patch interaction. I forked some projects and sent patches to
> their core, just to find out that they were inable to discuss the problems
> at hand. In that respect, the o so nice distributed model kind of never
> worked for me, because the theory didn't match with reality. If I see people
> complaining about patches that never get applied: thats no SVN problem.

Ah, that's for sure. No tool can supplant the availability of
developers at incorporating patches from the outside. However, git
_does_ make it easier to (1) keep private branches (2) rebase them (3)
publishing the changes for others.

> If they have to maintain their own branch and rebase it on head: git-svn
> solves this problem already. So I don't see the point where git and only git
> suddently makes ruby better.

Well, git-svn doesn't solve the problem optimally, as it's somewhat
clumsier to use than plain git, so having a git repository to begin
with is definitely better, even if you just have to keep your own
patches there forever. It also makes it easier for _others_ to rely on
your changes on top of the official git (not svn) repository. This is
why I say that having an official git repository, even if for the time
being it's just a mirror of the svn repo, is an important step in the
right direction.

-- 
Giuseppe "Oblomov" Bilotta