[LLVMdev] git

[Óscar Fuentes]

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.

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

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

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.

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

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

> If the argument is doing detached development, that is already possible.
> Approaches include the Git mirror, SVN mirroring solutions etc.
>
> Advocats of DVCS tend to ignore the cost of the move.

I'm not ignoring it. Actually, I'm one of those who are warning against
the "let's migrate the infraestructure and then all will be a path of
roses" view.

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

> This can be dealt
> with as part of a defined workflow, but that is far more work than just
> saying "use tool XXX" and I don't see this happening yet. At least on
> that point, we both agree.

Definitely, agreeing on a workflow and creating awareness about its
consequences is fundamental for the success of the switch.