[llvm-dev] [RFC] One or many git repositories?

[Justin Lebar via llvm-dev]

> That's assuming you're pushing directly to master. Very few people should be doing that!

I'm going to jump in and try to avoid a set of fifty emails arguing
various git workflows and how they integrate with gerrit, github, and
so on.

Yes, it is possible to come up with workflows that don't have this
problem.  But I don't think the monorepo needs to live or die on the
basis of the workflows we adopt, and this discussion is already
unwieldy as-is.

Can we keep that separate?

On Wed, Jul 27, 2016 at 2:59 PM, Bruce Hoult <bruce at hoult.org> wrote:
>
>
> On Thu, Jul 28, 2016 at 9:24 AM, Robinson, Paul via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>>
>>
>> > -----Original Message-----
>> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
>> > Justin Lebar via llvm-dev
>> > Sent: Wednesday, July 27, 2016 1:32 PM
>> > To: Chris Bieneman
>> > Cc: llvm-dev at lists.llvm.org
>> > Subject: Re: [llvm-dev] [RFC] One or many git repositories?
>> >
>> > Thanks for elaborating, Chris.
>> >
>> > > Case Study 1 - Simple development on a sub-project
>> >
>> > I explicitly addressed this workflow in my original e-mail.  I know it
>> > was a while ago, but it sounds like it may be worth a read if you
>> > haven't checked it out.
>> >
>> > In the mail I described how to use sparse checkouts to create a
>> > repository structure that functions virtually identically to what you
>> > have today.  It takes a few copy-pastable commands to set up.  If
>> > these few commands are a pain, we can write a script and check it in
>> > to llvm.
>>
>> If I try to push from my sparse checkout, but something that I don't
>> have in the checkout has changed, do I still need to rebase first?
>
>
> That's assuming you're pushing directly to master. Very few people should be
> doing that!
>
> If llvm is run like other github projects then you push to a branch in your
> own forked copy of llvm. No one else can push to that, so nothing can have
> changed.
>
> If you're developing your branch over a long time period then you should
> pull from master and rebase on that from time to time, and certainly just
> before making a pull request.
>
> The person responding to your pull request will rebase on the latest master
> and kick it back to you if there are problems.
>
> If gerrit is used for code review then the UI tells you if your patch is out
> of date compared to master and there's a big fat painless "rebase" button
> right there.
>