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

-----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 =20
> <[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 =20
>> bastard" side.
>
> Me too.
>
>> For example, one of my main reasons for darcs is it's nice cherry-=20
>> picking
>> interface that is the _default_ way of handling it. Sure, i could =20
>> use git
>> cherry-pick and friends, but Darcs gives me the collection of =20
>> features I
>> really like at my fingertips.
>
> Out of curiosity, what's so special about darcs cherry-picking =20
> interface?
>

Nothing really special, just that it flows nicely and is the default =20
way of interaction. So you don't have to decide to cherry-pick, you =20
have to decide _not_ to cherry-pick. It's not "advanced usage". If it =20=

was, I wouldn't use it (see the "lazy bastard" ;) ).

>> Also, I tend not to play with branches too much, but only push the =20=

>> 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 =20
developed two independent features in parallel on the same branch, you =20=

can then opt not to include one of them on the upstream. As long as =20
they are independent, you are totally allowed to do that.

It also forces you to somehow think about your patches again. So the =20
typical problem with "oh ****, I accidentally included a patch I =20
didn't want to push" vanishes.

>> Sure, I could push git into my workflow, but that would mean I =20
>> would have to
>> costumize git everytime I change computers. It does a lot, but i =20
>> only need
>> half of it and it always takes me time to figure out which half I =20
>> 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 =20=

alias for "git cherry-pick" and so on. In my experience, git has a =20
pretty equal distribution for all workflows. That means that my =20
preferred one doesn't really stand in the back, but it's also not up =20
front. I am a fan of specialized software. So I want one where my =20
workflow stands in front ;).
So git doesn't fit my needs, darcs does. No offense.

But in general, the darcs CLI is very though out and infomative. Thats =20=

what i like about it.

>> Also, if you allow both workflows, which link will you put on your =20=

>> website?
>> ;)
>
> That's definitely up to whoever maintains the website 8-D
>

So, that means that an interested committer has to adapt that.

>> As I said before: your mileage may vary. I don't like git that much =20=

>> 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. I =20
have a lot of stuff that I actually like about git (the vast =20
collection of transports to other upstreams, for example). But I also =20=

have the impression that user friendlyness is not one of the gits main =20=

goals (which - considering the type of programmer it was written for, =20=

is not very surprising).

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

a typical sign of a hype.

I don't want to argue that git is bad. I just don't see it as the =20
pinnacle of VCS evolution as some people try to sell it.[1] My example =20=

with darcs was to prove a point: the git glove doesn't fit for =20
everyone. The SVN glove doesn't, as well.[2] Same goes for hg and bzr.

Another word to the discussion. Switching to git doesn't fix the =20
biggest problems in patch interaction. I forked some projects and sent =20=

patches to their core, just to find out that they were inable to =20
discuss the problems at hand. In that respect, the o so nice =20
distributed model kind of never worked for me, because the theory =20
didn't match with reality. If I see people complaining about patches =20
that never get applied: thats no SVN problem.

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

Regards,
Florian

[1]: For example "Why git is better than X", where you still have to =20
skim through the HTML comments to see whats actually _bad_ about =20
git ;). And it states windows support.
[2]: But I also don't buy that it is worthless.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkll3oMACgkQyLKU2FMxSOJWDQCfcA8EtT3KkOB5FhiQOURb3j66
gm4AnRtPf6ojguNLBUBgsiD45sda0Pyl
=3DpXUN
-----END PGP SIGNATURE-----