[LLVMdev] git

[Joerg Sonnenberger]

On Sat, Jul 23, 2011 at 05:49:38AM +0200, Óscar Fuentes wrote:
> Joerg Sonnenberger <joerg at britannica.bec.de> writes:
> 
> > You know, this is exactly the crux of this whole "move to git" thread.
> > It is the very same problem of every other VCS migration I have seen (or
> > dealt with). The core issue here is that you are effectively telling us
> > that the current workflow is not supported by Git.
> 
> It is supported, but if you want to work svn-style, nothing better than
> svn itself.

Given that the svn-style workflow is not specific to svn, that sounds
like a good reason for not changing to git...

> > You are also telling us that the current workflow is in some way wrong
> > or misguided or suboptimal and has to change.
> 
> Suboptimal is the right word. There is nothing essentially wrong with
> everybody-and-his-cat pushing revisions to mainline but an user with
> write privileges to a git repo can make quite a bit of damage. Undoing
> that damage usually will cause inconveniences to everybody. Having a set
> of maintainers with write privileges that incorporates patches submitted
> to the mailing list, *maybe* is a better arrangement.

You are saying that git forces a different workflow because it is so
easy to mess up a repository with write access? I know exactly what you
mean. I have also dealt with bogus messed up work on other VCS and so
far, git beats them all. That's not exactly a good argument for git
though.

> > Let's avoid all the religious argument about how distributed version
> > control is somehow better than centralistic version control. What are
> > the precise gains from changing the status quo? What can you do by
> > moving everything to Git that you couldn't do in the current world
> > with svn as master repository and the additional git mirror?
> 
> git-svn is quite ok for lone developers doing experiments or coding
> small features, but if you work on a team and/or the changes are
> submitted on incremental steps, you have a problem because, for
> instance, git-svn will not recognize the revisions you contributed to
> the svn's repo as the same you and you co-workers already have in your
> git branch.

Either this makes git buggy or it isn't different from manually applied
patches in every other system I have dealt with. Heck, many patches
submitted to mailing lists are not committed as is, so you would have
merge overhead anyway. Especially the interesting non-trivial ones.

> If there is a feature that sets distributed version control systems
> apart from the traditional ones it is their role as communication
> tools. I can choose *not* to communicate my work to the public (or keep
> it within a restricted group) without giving out the convenience of
> using a version control system, or publishing my work on a way that it
> is easy for others to access, extend and incorporate into their own
> developments. Both this possibilities are positive for the project, for
> a variety of reasons. git-svn, as explained on the previous paragraph,
> is a hindrance for using the communication possibilities of git.

So this goes back to "it isn't git". Let's imagine for a moment that
LLVM would move to Mercurial. Most of your arguments would still apply.
Now, there is nothing wrong with using Mercurial on top of SVN.
Basically, all the good points of Git also apply to Mercurial. So
choosing it over Git gives pretty much the same advantages, but it still
doesn't address your specific concerns. Hm....

> > If the argument is "I don't like svn", it is weak. Others don't like Git
> > and would prefer Mercurial. Or Bazaar. Or maybe even Perforce or CVS.
> >
> > If the argument is better branching,
> 
> Better *merging*.
> 
> > 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.
> 
> Merging support in svn is brain-dead. Having a single commit "Merged
> branch foo rX:Y" is hardly informative. Having the actual chunk of VC
> history merged into the target branch is the Right Thing.

I can't even make sense of your statement. Subversion has merge
tracking, so it certainly keeps track of "where did this chunk of
history come from".

> > 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.
> 
> I'm sure that, conciously or not, the development policy of LLVM was
> conditioned by the limitations imposed by the VC tools the project used
> so far: CVS and svn (which is CVS refurbished). I can't believe that
> anyone thinks it is a good thing to scatter the commits that implements
> a feature all over the VC history, instead of atomically merging them
> á-la-git, with a parent-child relation that shows those commits as part
> of a logically consistent series and giving the precise point where the
> feature was incorporated into mainline.

Again, I can't make sense of your statement. I've done merging in both
CVS and svn of features. Both in the form of incremental patches and as
atomic patch. Surprisingly, both approaches work for different cases.
The cases where incremental and non-continious patches are used tended to
be larger scale changes to otherwise active parts of the tree, where the
overhead of permanent merging is greater. Merging in the
non-fast-forward sense for git speakers.

> > The linear commit
> > graph and associated properties is the biggest one.
> 
> However, I'm also saying that if the loss of the LG (Linear Graph) is
> the biggest one, then the stumbling rock for adopting git is not
> realizing its potential. The LG is convenient for some tasks, but it is
> also a limiting factor for others. You are accustomed to its
> conveniences and accepted its limitations (possibly without much
> thinking). You are not accustomed to the advantages of using a tool like
> git. Once the transition is *correctly* done, the loss of the LG will
> seem as a petty one.

You still have given me a good argument for giving up the convience. All
you have been talking about so far are issues of git.

Joerg