Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-02-09 06:53:21

On 02/09/2012 12:08 PM, Tim Blechmann wrote:
>>> with svn your working copy gets easily out of sync ...
>>
>> svn update is all you need. ever. There are conflicts from time to time.
>> Man up resolve them.
>
> true, but in my experience resolving conflicts with svn is much more fragile
> than with git ...
>
>>> the nice thing of git is that it does not really harm if your branch
>>> diverges from upstream, as its merge facilities are much more
>>> sophisticated than everything that subversion has to offer ...
>>
>> I've heard that a couple of times now. My personal experience with git
>> however is quite the contrary. I regularly mess up my local repository.
>
> well, you need to have an understanding of what you are doing ... but at least
> all you changes are stored inside the local repository. if you mess with your
> local changes, you can revert to them, if you mess with a working copy, you
> mess with files that you cannot got back to ...

Right, and there are plethora of ways to mess up local copies with git. 
While it might be possible to get back in a sane state it is extremely 
hard. As said, especially with the features everything advertises here, 
it gets really hard to maintain something like a mainline git repository.

>>> frankly, since i moved my code into boost's svn, i find it way more
>>> fragile to maintain than before
>>
>> Yes, I used to advertise git too. I had the exact same experience. That
>> goes away. After a while, you won't look back to git, and enjoy "svn up"
>> and "svn commit" and
>
> svn was a relief for me after using cvs ... i've had the same feeling when
> switching to git a few years later. using svn again (for boost), it really
> feels like a bad joke ...
>
>
>> start to question the usefulness of decentralized
>> version control systems for a centralized boost altogether.
>
> just because git is decentralized does not mean you cannot use it for
> centralized projects.

All I am asking is: what's the point? If it is used as we use svn 
currently, why change at all?

So far, I've only heard stuff like: "X is extremely easy to do with git 
(If it is done right, and you know what you are doing, otherwise you are 
screwed)" (paraphrased).
As others hinted, git should probably seen as a "meta VCS", the workflow 
matters.
I definitely can see that something like the "linux model" makes sense 
for certain libraries. Git was obvously designed for it. However, 
whenever I tried to use all those nice and funky features (ease of 
branching and merging etc.). I always lost a lot of time because 
something didn't work as i expected. After asking people who are 
supposed to know the stuff, they told i did it wrong and i should use 
another tool in the git toolset. So I did that the next time and ended 
up right at the beginning.

Sorry, I really tried to use git. It is all nice if you are alone and 
keep developing for yourself and push feature. However, when there are 
more people involved, with all kinds of branches etc. I always lost 
track and messed something up. Be it that something didn't compile for 
others cause merging failed, be it that history was completely borked or 
that I myself had the hassle to rewrite history so it all worked out 
again. In the end my experience was that all the nice features you are 
describing are not worth the hassle and do more harm than they are worth.

Of course, chances are high that i just did it wrong.
So, what i would like to see from you guys is a definite guide to use 
git. A description of workflow for both maintainer, contributor and 
whatever other role you can think of, and a playground to test that out.
Otherwise, I don't see a lot of value in such discussions.

> tim