-----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  
> <flo / andersground.net> 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  as, I wouldn't use it (see the "lazy bastard" ;) ).

>> 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  an 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.

>> 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  lias 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.

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

>> 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.

>> 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. 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  ave the impression that user friendlyness is not one of the gits main  oals (which - considering the type of programmer it was written for,  s not very surprising).

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  ypical sign of a hype.

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  ith 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.

Another word to the discussion. Switching to git doesn't fix the  
biggest problems in patch interaction. I forked some projects and sent  atches 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.

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.

Regards,
Florian

[1]: For example "Why git is better than X", where you still have to  
skim through the HTML comments to see whats actually _bad_ about  
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
=pXUN
-----END PGP SIGNATURE-----