[LLVMdev] git

[jo at durchholz.org]

> On Sat, Jul 23, 2011 at 01:02:10AM +0200, Óscar Fuentes wrote:
> What can you do by moving everything to Git that you
> couldn't do in the current world

Get the history of a piece of code that was refactored to a different file.
SVN cannot do this, git can.

No network latency, i.e. faster operations and less interruptions of the
train of thought.

> with svn as master repository and the
> additional git mirror?

More alternate workflows as they are useful.

> If the argument is better branching, I would like to see it clarified
> for how this improves the workflow. I have dealt with many open source
> projects and many VCS variants. I don't see a noticable improvement from
> using Git compared e.g. to SVN for sane usage of branches -- be it
> short-term feature branches, mid-term restructoring or long-term release
> branches. The exception may be doing wild cross branch merging and long
> dependency chains between branches like done in the Linux kernel -- but
> I don't think that's a sane development model and I certainly don't see
> that agreeing with the development policy of LLVM.

The Linux people would probably strongly disagree that their development
policy is insane. And they have a history of success to back up their
claims.

> If the argument is doing detached development, that is already possible.
> Approaches include the Git mirror, SVN mirroring solutions etc.

Slow, so done less often than what people would want to do.

> Advocats of DVCS tend to ignore the cost of the move. The linear commit
> graph and associated properties is the biggest one.

You don't have a linear commit graph unless you disallow merges in the
project policy.
Independently of whether you use svn or git.

svn does present you with a "trunk" branch that runs linearly, but that's
just a convention, and can even be misleading (when the most important
changes in a piece of code were done in a branch and merged later).

> This can be dealt
> with as part of a defined workflow, but that is far more work than just
> saying "use tool XXX"

Yep, switching to git would require a lot of work on the project
maintainers' side. Commit hooks, setting up repositories, rewording
policies in terms of the commands of the new tools, and that only to
regain the status the project already has - to actually reap benefits in
the form of workflow flexibility, there's even more investment in trying
that out.

The one instant benefit that I see is content tracking instead of by-file
tracking.
Still, there's a learning curve.
In the end, I guess it's the team's decision :-)