Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Nigel Stewart (nigels.com_at_[hidden])
Date: 2012-02-10 23:56:12

> All I was trying to say is: why should i bother learning a
 > new tool, when it doesn't solve anything.

The popularity of git by itself suggests to me that it's
worth paying attention to.  I've seen many projects switch
from svn to git.  And none switching from git to svn.

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

The key difference with git is that there is less of a
client/server distinction.  Every client (where development
happens) is the same as a server, in terms of having all
the revision history.  Changes flow from one repository
to another, one branch in one place, to some other branch
somewhere else, generally without manual merging, diff or
patch steps.  Occasionally there are conflicts that need
manual resolution.  But generally, rebasing is painless.

> Which repository do i choose to fork from? Mainline?
 > The one of the maintainer? A special branch with some new features?

Precisely the one that is most relevant.  In a nutshell -
the one you're most likely to want to upstream your changes
to.

If the maintainer of boost.foo wants to accept patches into
a repository entirely under their control - then periodically
upstream those to an official boost branch - so be it.

> What if it is not really up to date (Yes, last time i
 > checked you still have to manually update your source)?

Then rebase against something else, the common history will
be well utilised in the process.

> All you hear is that git is so great, and you can
 > branch and merge back however you want.

The practical problem I face is maintaining a patch set
for an old version of boost.  Without the "local full revision
history" I need to do a lot of manual rebasing to bring
that patch set forward to a modern version of boost.
Indeed, without doing this work there isn't much prospect
of getting those finally accepted back into the mainline
boost.  I would fully expect this to be far less of an
issue using git, if only because I've had good experience
managing a few divergent branches of codebases with
git, versus what seems extremely limited features of svn.

One of the surprising aspects of git is the "malleability
of change history" quite unlike cvs, svn or perforce.
The timestamps need not necessarily be monotonically
increasing from one revision to the next.  I guess in
principle I could refactor a change in order to merge
some subset of it to some other branch/repo.  Try doing
that with svn.  I mean really...

- Nigel