Re: [boost] [git] neglected aspects

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

On 02/09/2012 03:16 PM, Steven Samuel Cole wrote:
> Thomas Heller wrote:
>> svn update is all you need. ever.
>  > ...
>  > you won't look back to git, and enjoy "svn up" and "svn commit"
>
> these statements give me the impression you have actually not yet walked
> in the shoes of a branch maintainer / integrator; i don't see how you
> would do that without at least 'svn merge'. as such, i'm not sure if you
> have experienced the problems of merging / integrating a development
> line first hand and can appreciate the conceptual advantages git has to
> offer in that area.
>
> Thomas Heller wrote:
>  > There are conflicts from time to time.
>
> are you talking about conflicts you get after an svn up ??
> those are certainly not the reason why DCVSs exist - but git helps with
> that, too ;-)
>
> Thomas Heller wrote:
>  > Man up resolve them.
>
> i don't know the details of how things are run in boost, but in my
> experience, the job of an integrator is the one with the worst
> responsibility to appreciation ratio in a software project:
> if they screw up, everyone will notice due to the bad release;
> if they deliver 100%, they rarely ever get the praise they deserve.
>
> i've seen companies where developers who have fallen from favor with
> management were forced onto the integration chair until they either
> resign or go mad. telling them to man up without having been down that
> road in a high profile commercial or large, popular open source project
> is... not something they will like to hear. of course you can not know
> this, but the mere memory of this situation still makes me twitch. i do
> hope that doesn't show in my tone, my apologies if it does.

In boost, library maintainers merge into the release branch before every 
release. I did that for the last several boost releases for 
Boost.Phoenix. I did not have any problems.

> Thomas Heller wrote:
>  > The git userinterface is just a pain,
>  > i regularly get confused and have no idea what to do.
>  > ...
>  > I regularly mess up my local repository.
>
> I find myself doing a lot of 'git status' in a version-controlled folder
> which gives me info like
>
> host:folder user$ git status
> # On branch some_feature_branch
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: main.cpp
> #
>
> or
>
> host:folder user$ git status
> # On branch some_feature_branch
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # modified: main.cpp
> #
>
> one single command and the tool tells you what you could do next.
> how much simpler and more user-friendly could it possibly be ?
>
>
> Thomas Heller wrote:
>  > 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.
>
> what it 'extremely hard' about 'git reset --hard' ? (no pun intended).

And lose all the work? I am not sure what exactly you were trying to 
tell me.

> host:folder user$ git status
> # On branch some_feature_branch
> nothing to commit (working directory clean)
>
> btw: i've come across http://githowto.com today, maybe that helps to get
> past the initial learning curve.
>

All I was trying to say is: why should i bother learning a new tool, 
when it doesn't solve anything.
All I was saying is that you described the exact same process in your 
initial mail that is possible with SVN. It is not a tool problem. It 
might be true that git or any other DCVS enable different workflows. But 
as you described it, it is exactly the same. The problems of bugs not 
being solved, or patches not being applied does not magically go away. 
The fact the regression test setup is suboptimal does not suddenly go up 
in smoke. My personal feeling is that this will even be worse with git:
Which repository do i choose to fork from? Mainline? The one of the 
maintainer? A special branch with some new features? What if it is not 
really up to date (Yes, last time i checked you still have to manually 
update your source)? How will new features be tested?
These are all things that noone considered. All you hear is that git is 
so great, and you can branch and merge back however you want. I did not 
have that experience. I experienced serious trouble with git. So I am 
asking you again: What exactly do you propose?