Just to be up-front, I normally work on very small projects and I am very much a non-core LLVM developer (I'm the MicroBlaze backend maintainer). However, we have had success where I work using the git branching model described in [1] and [2]. There is a git tool named "git-flow" that specifically supports this model and it seems like it might fit the LLVM development model so I wanted to point it out in case others had not seen it. Perhaps the more core developers can comment more on its usefulness in the LLVM ecosystem. [1] http://nvie.com/posts/a-successful-git-branching-model/ [2] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ -- Wesley Peck University of Kansas SLDG Laboratory On Jul 23, 2011, at 3:16 PM, FlyLanguage wrote:>>> Yes, but who's mainline? Is the plan to have a centralized repo with a mainline branch that everybody pushes to >> >> This one. >> >>> , or the a linux style model where some person has an official mainline to which he pulls? >> >> Not this one. >> >> This shouldn't be a mysterious concept, our policies are well documented here: >> http://llvm.org/docs/DeveloperPolicy.html#policies > > > No mystery, just nice to know which setup llvm will have. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > There is a git tool named "git-flow" that specifically supports this model > and it seems like it might fit the LLVM development model so I wanted to > point it out in case others had not seen it. Perhaps the more core > developers can comment more on its usefulness in the LLVM ecosystem. > > [1] http://nvie.com/posts/a-successful-git-branching-model/ > [2] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ > >I was reading through the thread and was going to post a link to the same blog post when I came across yours. While I have not use 'git flow', I have used the same branching model (both in Perforce and git) and like it quite a bit. I don't see why changing to git would require (or even suggest) any change in the current LLVM policies, and I would suggest that the 'pull model' (very nicely supported by GitHub) is actually in line with the way I understand LLVM development policies and might be a nice addition if desired. In fact using a site like GitHub nicely automates the code review and commit process, and ensures that requests for review and commit aren't lost. On the comments about submodules/superprojects, I will agree they are slightly confusing at first, but it's primarily the people setting up the submodules that have to overcome that confusion. For en users they generally only need to care about running slightly different commands if they want to init and sync the superproject and use it to maintain the appearance of atomicity across projects. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110723/6a354955/attachment.html>
Mark Lacey <641 at rudkx.com> writes:> On the comments about submodules/superprojects, I will agree they are > slightly confusing at first, but it's primarily the people setting up > the submodules that have to overcome that confusion. For en users they > generally only need to care about running slightly different commands > if they want to init and sync the superproject and use it to maintain > the appearance of atomicity across projects.Not true. The individual developer must make sure never to commit within a submodule directly. That is extraordinarily confusing. git-subtree eliminates that restriction. -Dave