<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<br>

<br>
[1] <a href="http://nvie.com/posts/a-successful-git-branching-model/" target="_blank">http://nvie.com/posts/a-successful-git-branching-model/</a><br>
[2] <a href="http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/" target="_blank">http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/</a><br><font class="Apple-style-span" color="#888888"><br></font></blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Mark</div><div><br></div><div><br></div></div>