[LLVMdev] git

[John Criswell]

On 7/28/11 4:40 PM, David A. Greene wrote:
> Chris Lattner<clattner at apple.com>  writes:
>
>> On Jul 25, 2011, at 3:22 PM, Jason Kim wrote:
>> Great point.  A potential conversion to git should be motivated by its
>> benefits - assuming no development policy change - and that benefit
>> needs to be greater than the various costs of conversion.
> Here are the most important benefits I see for the LLVM projects:
>
> - git greatly simplifies the work for groups that want to keep a private
>    repository for internal development but eventually want to move that
>    code to the public repository.  Right now, there is NO tool support
>    for doing this.  It is a royal pain.
>
> - git allows different groups to share a codebase outside of
>    master/upstream.  Think of two academic research groups who want to
>    explore a new transformation but don't want that work pushed to the
>    public until it's done and published.  This kind of development has no
>    support whatsoever in svn.

Just to offer an alternative perspective on the above point, I suspect 
that one of the reasons why maintaining out-of-tree code is such a pain 
is because people are adding their passes into LLVM instead of using the 
LLVM projects system.

For those unfamiliar with it, the LLVM projects system allows external 
software source trees to link into LLVM's build system.  Source code in 
the project uses LLVM header files and libraries just like in-tree code, 
and project Makefiles look nearly identical to LLVM's Makefiles.  The 
whole purpose of the project system is to allow people to write their 
own LLVM passes in their own source trees (which, of course, can live in 
its own revision control system) as if they were writing in-tree code.

Moving code from a project into LLVM shouldn't be terribly difficult, 
especially if you write it so that the code is within the llvm namespace 
and you create a local include/llvm tree for header files (aside: we 
didn't do this for SAFECode, which made the SAFECode patch to LLVM more 
difficult than necessary to create.  Live and learn).

The projects system is used extensively here at Illinois (the publicly 
available SAFECode and Poolalloc projects use it, and we have another 
three internal projects using it) and is documented at 
http://llvm.org/docs/Projects.html.

I think the main drawback of the projects system is that it doesn't work 
for modifications of LLVM (including core LLVM changes, changes to 
existing transforms, and code-generator changes).  However, for writing 
transform/analysis passes and LLVM-based tools, it works fine.

-- John T.

>
> - git provides a set of tools built-in to interact with the submit patch
>    ->  review ->  update patch ->  submit patch iterative process.  I'm
>    thinking mainly things like git send-email, git rebase -i and git add -i.
>
> - git allows easy backtracking of decision points, allowing one to
>    explore a line of development and then reformulate the set of commits
>    made before actually sending them upstream to master.  For me, it is
>    more helpful to be able to just code up a feature and once it's
>    working, go back and break out the individual patch sets into logical
>    groups.  I tend to poorly anticipate how a feature/fix should be
>    presented to upstream before I've actually implemented it.  git
>    decouples those two activities.
>
>                                 -Dave
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev