Subject: Re: [boost] [git] neglected aspects
From: Steven Samuel Cole (steven.samuel.cole_at_[hidden])
Date: 2012-02-09 09:54:41
Edward Diener wrote:
> Tell me how git magically manages to merge changes by multiple
> developers to the same file when a local repository is pushed to another
> one somewhere else.
of course git does not magically solve that.
i think the difference between svn and git to some extent is a different
mentality: while both technically do support branching and merging, the
process is much more heavyweight in svn than in git:
an svn branch is often considered to last for weeks or months or even
permanently - and once the big new feature it was created for has
reached release maturity, merging the changes back in is a rather
releases have failed because of this - code builds fine in dev branches,
but once it's all merged, nothing compiles. this integration problem is
one of the reasons why the whole continuous integration concept has come
up in the last decade, see
git circumvents this problem to some extent by anticipating the need for
branches and merges as a central concept and incorporating it on a much
lower level than svn; branches are much more lightweight and are
possibly created and merged back in several times a day.
Edward Diener wrote:
> I feel like the little boy declaring that the emperor has no clothes.
No need - a certain amount of scepticism and critically questioning a
proposed change is necessary to verify a concept is sound.
I was not really convinced of git's benefits until I actually gave it a
good test run on a small open source project on github. Takes only a
couple of minutes.
I also found I had to let go of my conventional understanding of source
control systems: In contrast to a central svn server where one single
head revision is pushed forward by changes from the team, git feels to
me more like sets of changes are passed around between local repos - and
one of them - one that gets special TLC - is the master branch.
Does that makes sense ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk