[lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
Mehdi Amini via lldb-dev
lldb-dev at lists.llvm.org
Wed Jun 29 21:03:09 PDT 2016
> On Jun 29, 2016, at 10:03 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Hi all,
> A short summary: Takumi has done 90% of the work here:
> 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.
That makes it fragile, and that’s why I disagree with your “90% done” assessment.
What if the service behing the hook is down for a few days? Who will maintain it?
> 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:
> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the lldb-dev