[LLVMdev] git

Jeffrey Yasskin jyasskin at google.com
Thu Jul 21 11:58:52 PDT 2011

On Wed, Jul 20, 2011 at 10:46 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Wed, Jul 20, 2011 at 9:32 PM, Chris Lattner <clattner at apple.com> wrote:
>> On Jul 20, 2011, at 11:47 AM, Jakob Stoklund Olesen wrote:
>> >>> If you can work with Jeffrey to come up with better instructions, that
>> >>> would be great.
>> >>>
>> >>> Just make sure they are newbie-proof.
>> >>
>> >> Wouldn't it be easier at some point to move llvm.org to git?
>> >
>> > Definitely.
>> I think that I'm the one who previously strongly objected to doing so.  I
>> now remove my objections, I think that git has both matured enough and has
>> succeeded in "winning" the distributed VCS war.
> Based on this comment, and some conversations on the IRC channel, I'd like
> to offer to work on such a conversion. I think there are a lot of sticky
> details to work out, but I think it will be very positive move. I'm going to
> start working on a rough plan for how to do the conversion, and what the
> final system should look like.
> Any key things people want to see in it? Any key concerns? As soon as I have
> something written up I'll post it here.
> Key things I'm currently thinking about after a brief brainstorm:
> - Post-commit triggers need to be ported and kept useful
> - Special attention to ensure that the existing code review / commit email
> system continues to be effective
> - Provide individual git repositories for each LLVM project, along with meta
> repositories that use submodules to layout common development trees (e.g.
> Clang in tools/clang)

This may be included in your second bullet, but we probably want a
style guide of some sort for how to present changes when they're
committed to the main repository. Should every commit pass tests, or
is it ok to have 1 line per commit? Should we create a merge commit
with --no-ff to cap a series of changes and describe the feature? Do
we want to try to keep the main repo's history mostly linear with
local rebases or are lots of merges ok? Are there tools to help
enforce whatever style people want?


More information about the llvm-dev mailing list