[lldb-dev] Git Move: GitHub+modules proposal

Renato Golin via lldb-dev lldb-dev at lists.llvm.org
Wed Jun 29 07:03:43 PDT 2016


Hi all,

A short summary: Takumi has done 90% of the work here:

https://github.com/llvm-project/llvm-project-submodule

and I've been talking to GitHub, and here are the answers to my questions:


> 1. How will the umbrella project's auto-increment hook work?

Since the umbrella project cannot see the sub-modules' commits without
some form of update, there are two ways to do this:

P. Per push: Every push (not commit) on all other repositories will
trigger a hook that will hit a URL on our server, telling it to
generate an incremental ID, update some umbrella's SeqID property (or
even a commit SHA) and update the sub-modules.

T. Time based: A cron job in our server would frequently pull from all
repos and update ID/modules.

Option P is less confusion and more fine grained, but if it misfire,
we'll lose that push, and its commits will be bundled with the next
push on that repo.

Option T will invariably bundle things together, even from different
repositories. The change that this will "correctly" merge an
LLVM+Clang double-patch is not worth the trouble for the noise.

For both of them, we need an external server, as there's no way to
update a repository's property from another.

Multiple commits eventually getting into a single umbrella revision
can be innocuous for development, but they can make controlling the
version for releases a bit more complicated. Though, it would also
have no effect on back-ports, since they'll be done on Git and get
their own SeqID.

All in all, I'm not too worried about this...


> 2. How do we update the commits mailing lists?

This is, apparently, trivial in GitHub:

https://help.github.com/articles/managing-notifications-for-pushes-to-a-repository/#enabling-email-service-notifications-for-pushes-to-your-repository

Any more comments before we put this proposal to vote?

Is anyone going to propose an alternative Git solution?

Or maybe an external, reliable and trustworthy SVN repository (ie.
*not* SourceForge)?

In the interests of brevity and peacefulness, we should aim to only
have one vote, even if it has multiple choices, so if we have more
proposals, please bring them up.

cheers,
--renato


More information about the lldb-dev mailing list