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

Wed Jul 27 12:10:11 PDT 2016

Hi Mehdi,

Thanks so much for writing this up! This will help many people who are
struggling to keep up with the post influx including myself :)

> gives insights to the most common workflows

I must disagree with you here and this is the basis of all my messages; it
gives an insight into workflows but not their commonality. Only their
commonality among those who spoke up. That's why I believe it should be
*supplemented* with a survey of some kind. That is all I was trying to say
:)

James

On Wed, 27 Jul 2016 at 19:47, Mehdi Amini <mehdi.amini at apple.com> wrote:

> On Jul 27, 2016, at 11:38 AM, James Molloy via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi Justin,
>
> Firstly I really appreciate you taking the mantle and pushing this
> forward! Like Justin B I'll be bowing out after this.
>
> I thought it important because I don't believe you'll build consensus in
> this threathese thred.
>
>
> Is it possible to reach “consensus” on such issues?
>
> I think the best that can be hoped for is opposition to give up fighting;
> advantages are to be had on both sides by different types of user and we've
> seen that many times in this thread.
>
>
> At some point there will be a need to acknowledges priority, people have
> conflicting workflow/goals and we’ll have to make a choice to favor one
> workflow instead of another.
>
> I value a lot threads because it gives a lot of insights on the most
> common workflows and we can build a proposal that account for *most* and
> reduce as much as possible the inconvenience for the others.
>
> Here is what I gathered till now:
>
> About git itself:
>
> - Aaron Ballman (with +1 from George Rimar): "Not everyone thinks git is a
> step forward. Please do not force people to use a "git-only" solution.”
>  (It seems that github has a SVN R/W access)
> http://lists.llvm.org/pipermail/llvm-dev/2016-May/100318.html
> - Joerg Sonnenberger: does not like git and prefer mercurial, didn’t find
> an email with a rational though.
> - Chris Matthews:  LNT / llvmlab-bisect needs currently a sequential ID
> number http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html
> - Mehmet Erol Sanliturk: "I consider revision numbers as only a disastrous
> design” http://lists.llvm.org/pipermail/llvm-dev/2016-May/100329.html (+some
> criticism of the GitHub UI).
> - Scott Warren: "find [git] immature, hard to use, and unreliable.”
> http://lists.llvm.org/pipermail/llvm-dev/2016-June/100514.html
>
> About monorepo vs submodules:
>
> - [multiple people]: need the ability to bisect (right now it’s not ideal
> and people are cloning the github monorepo). Both solution allows this, but
> some annoyance with submodules were countered with “developers don’t need
> to checkout the umbrella repo” which does not line up. Joerg mentioned as
> well “my primary interaction with the VCS for me is bisection, anything
> making it more fragile or more difficult to work is a huge no” (against
> submodules).
> - Justin Lebar: opening this thread with many arguments in favor of the
> monorepo: http://lists.llvm.org/pipermail/llvm-dev/2016-July/102602.html
> - Paul Robinson: "major drawback of a single huge repo IMHO: In git, to
> push a commit you must have it at the remote HEAD. If HEAD has changed
> you need to rebase/rebuild/retest/retry. With a single monster repo, a
> commit to 'lld' means I have to go through this pain to put in my 'clang'
> tweak.”, http://lists.llvm.org/pipermail/llvm-dev/2016-July/102656.html
> - Justin Bogner: " it's easy[1] to manage the set of repos with a script
> that cd's to each one and runs whatever git command.” And " if all of the
> repos are combined into one, you have to do work when you only want some of
> them. In my experience, this is basically always”.
> http://lists.llvm.org/pipermail/llvm-dev/2016-July/102609.html
> - Mehdi: "the minor inconvenience in the case of the monolithic
> repository is happening during the initial setup/clone/checkout, and not
> during day-to-day development (git pull, git checkout -b, git commit, git
> push), while the split model induces “minor inconveniences” in the
> day-to-day developer interaction. I.e. I prefer using a script to checkout
> and setup the repo, and then be able to use the standard git commands for
> interacting with it.”
> http://lists.llvm.org/pipermail/llvm-dev/2016-July/102612.html
> - Chris Bienemann: What about a contributor only wanting to contribute to
> compiler-rt? He has to pay the price of cloning the full repo.
> http://lists.llvm.org/pipermail/llvm-dev/2016-July/103052.html
>
>
> On linear history and sequential revision number:
>
> - [multiple people]: we should keep a linear history (haven’t found good
> reasons). Note that no Github proposal (submodule or monorepo) are
> addressing this. Tim proposed a solution based on checked-status but it
> requires every developer to run a script on their local machine before any
> push.
> - Chris Lattner: "I think we *want* to severely limit how history is
> allowed to look.  We don’t want the entire development history of your
> long-lived branch coming to mainline.”
> http://lists.llvm.org/pipermail/llvm-dev/2016-June/100665.html
> - Mehdi: "bug is fixed in r12345, my binary says "clang -v" is r23456 [or
> bot says it tested r23456], if I observe the bug [or the bot still fails] I
> know there is a problem immediately."
>
>
> —
> Mehdi
>
>
>
>
>
>
> James
> On Wed, 27 Jul 2016 at 19:33, Justin Lebar <jlebar at google.com> wrote:
>
>> Maybe we can hit the pause button on this issue of a survey vs
>> consensus-building.  I think it's a distraction from the main issue
>> here, and it makes it harder for everyone else to participate in the
>> thread.
>>
>> That said, I really do think that perspectives like Justin B's below
>> are important.  That is, if people have a problem with the monorepo,
>> it is useful they can join the thread and say why.  That's true
>> regardless of whether we use a survey or not.
>>
>> -Justin
>>
>> On Wed, Jul 27, 2016 at 11:29 AM, James Molloy via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > Hi,
>> >
>> > That's why we collate responses and provide summaries and proposals,
>> which
>> > is what Renato did. There are a lot of technical deep dives on this
>> thread
>> > that make it difficult to keep track of where consensus is going.
>> >
>> > Besides which we surely care about all our users and developers, and not
>> > just the loud ones or ones with enough cajones to chip in on a massive
>> > thread full of big names without fear of embarrassing themselves. We
>> also
>> > surely don't want a slew of '+1 to the proposal 93 replies ago'; how
>> does
>> > that help anyone decide if consensus is reached?
>> >
>> > How can you decide that people who don't see this thread don't get the
>> > chance to vote? It's summer time and people *will* be on vacation. Do
>> you
>> > expect them to find this in their inbox when they come back and read
>> through
>> > every response? This is not realistic.
>> >
>> > James
>> >
>> > On Wed, 27 Jul 2016 at 19:23, Krzysztof Parzyszek via llvm-dev
>> > <llvm-dev at lists.llvm.org> wrote:
>> >>
>> >> On 7/27/2016 1:04 PM, James Molloy via llvm-dev wrote:
>> >> > This thread is not particularly inviting. It has over 300 replies at
>> the
>> >> > time of writing and we don't all have the time to delve into such a
>> >> > quagmire. That doesn't mean our opinions are worthless.
>> >>
>> >> It doesn't take reading all responses to see where the discussion is
>> >> going. Important decisions take time to make. People took a lot of
>> >> effort in this thread to present their ideas and to address various
>> >> concerns. I bet they all have other things to do as well.
>> >>
>> >> -Krzysztof
>> >>
>> >> --
>> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> >> hosted by The Linux Foundation
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> llvm-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160727/3eb4d300/attachment.html>