[LLVMdev] git Status Update?

[Wesley Peck]

Just to be clear and upfront, I don't particularly care if the master repository is git or svn. I'm not a full time LLVM developer and I just use git-svn when needed. That said…

On Sep 9, 2011, at 10:36 AM, Garrison Venn wrote:
> I believe the concern here is concentrating on how owning devs + others 
> conduct incremental patch reviews in conformance with the current LLVM/svn 
> based practice. IMHO any automated approach, such as your suggestion, would
> have to incorporate this concern, while simultaneously not forcing core devs to
> temporarily stop their current LLVM work in favor of learning a new review process,
> and possibly having to retool 3rd party dev tools.

There is a bit of a catch-22 here. It seems like the core developers want only minor interruptions to the patch management and revision control methodologies, probably because these tasks are tedious enough as is. However, in my opinion, git doesn't really shine until you go "all in". That is why it has been difficult to enumerate an obvious advantage of git, you don't get much of a benefit by just converting the central repository to git. To get an advantage you need to move most of your infrastructure to git and this is a non-trivial interruption to the workflow.

For instance, all of the project references below have some sort of tool support for tracking patch submissions and performing code review. In particular, it seems like Gerrit would meet the needs and usage style of the LLVM project. Additionally, cheap branching means its faster and easier to apply and build a patch without interrupting your workflow. My guess is that life would be easier for core developers and patch reviews would not get lost in the ether as often (not that this happens that often in the LLVM project).

Like I said, setting one up and changing to it would be tedious and would probably cause a non-trivial interruption in LLVM development for a time. For core developers and/or the LLVM project, the resulting payoff may not be worth the cost of the interruption. One thing that may help mitigate the cost of a change would be git's support for local commits and distributed patch sharing.

[1] http://code.google.com/p/gerrit
[2] http://source.android.com/source/life-of-a-patch.html
[3] http://unethicalblogger.com/2009/12/07/code-review-with-gerrit-a-mostly-visual-guide.html
[4] http://www.gitorious.org
[5] https://github.com

--
Wesley Peck
University of Kansas
SLDG Laboratory