similar to: Questions on Clang's documentation of Modules

peanut gallery comments from a git hater (We use git for all source revision control) On Wed, Jun 1, 2016 at 3:31 AM, Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> wrote: > Folks, > > There has been some discussion on IRC about SVN hosting and the perils > of doing it ourselves. The consensus on the current discussion was > that moving to a Git-only solution would have

Hi, > On Sep 7, 2016, at 10:30 AM, dag at cray.com wrote: > > Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Right, we actually have a proposal to take what is in the current SVN >> repo here: http://llvm.org/svn/llvm-project/ and migrate this to a >> single repository. >> I was not sure if you were referring to this proposal

>> As for updating the meta repository: We could disable write access for the normal llvm developer and delegate the submodule bumping to an external >> server. I believe this would be an easy enough job for buildbot or jenkins. > > The plan is to disable all write access to this repository (otherwise > we'll create a nightmare). Having an external counter could be >

It has also submodules. https://github.com/llvm-project/llvm-project-submodule Both llvm-project(-tree) and (-submodule) have refs/notes/commits. On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 27 June 2016 at 17:03, Rafael Espíndola <rafael.espindola at gmail.com> > wrote: > > I think that trying to create a

On 28 June 2016 at 06:55, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > It has also submodules. > https://github.com/llvm-project/llvm-project-submodule > > Both llvm-project(-tree) and (-submodule) have refs/notes/commits. Nice! Can you try a server hook that will add an auto-increment number from submodules commits? cheers, --renato

> > Message: 2 > Date: Thu, 29 May 2008 06:35:01 -0700 > From: David Chelimsky <dchelimsky at gmail.com> > Subject: Re: [rspec-users] Coloured output in rspec 1.1.4 > To: rspec-users at rubyforge.org > Message-ID: <175B70FE-B706-4C03-8B20-C5B207268AD6 at gmail.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > On May 29, 2008,

> On Jul 22, 2016, at 1:16 AM, Simon Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Ill start by saying Ive skimmed this thread and am not actually a user of LLVM at all, but had some git thoughts that might be worth contributing. > >> On 22 Jul 2016, at 01:16, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>

Building on the great work that James Knight did on migrate-downstream-fork.py (Thanks, James!) [1], I've created a simple tool to take migrated downstream fork branches and zip them into a single history given a history containing submodule updates of subprojects [2]. With migrate-downstream-fork.py, one is left with a set of unrelated histories, one per subproject: llvm

> On Jun 2, 2016, at 11:22 AM, dag at cray.com wrote: > > Matthias Braun via cfe-dev <cfe-dev at lists.llvm.org> writes: > >> 3. Make sure we have ala llvm-project-submodules setup in the official >> account. (Optional or necessary for the buildbots?) > >> 7. Make sure bisecting with llvm-project-submodules is a good experience > > I would like to

> On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote: >> To be more exact here: I usually do not checkout llvm svn at a higher >> level because that forces me back to svn (which last time I used it did >> not have built-in support for bisection, not

He all, I've updated the downstream fork zipping tool that I posted about last November [1]. It is much improved in every way. The most important enhancements are: - Does a better job of simplifying history - Handles nested submodules - Will put non-submodule-update content in a subdirectory of the monorepo - Updates tags In addition there are plenty of the requisite bug fixes. The

Björn Pettersson A <bjorn.a.pettersson at ericsson.com> writes: > In the new monorepo UC1 may or may not be a parent to UL1. > We could actually have something like this: > > UL4->UC2->UL3->UL2->UL1->UL0->UC1 > > Our DL1 commit should preferably have UL1 as parent after > conversion > > UL4->UC2->UL3->UL2->UL1->UL0->UC1 >

This is a request to split up the repository into at least two repositories rspec rspec_core (loaded as svn_external or git submodule) rspec_on_rails (loaded as svn_external or git submodule) We could load the plugins the same way as before ruby script/plugin install http://rspec.rubyforge.org/svn/trunk/rspec_core ruby script/plugin install

On 27 June 2016 at 22:55, NAKAMURA Takumi via cfe-dev <cfe-dev at lists.llvm.org> wrote: > It has also submodules. > https://github.com/llvm-project/llvm-project-submodule > > Both llvm-project(-tree) and (-submodule) have refs/notes/commits. I really like this too, and think Takumi has basically solved 90% of the problem for us already. We may want to add an "rN" line

On Tue, May 31, 2016 at 02:43:02PM -0700, Matthias Braun wrote: > > > On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote: > >> To be more exact here: I usually do not checkout llvm svn at a higher > >> level because that forces me back

I think it is erroneous to have the subrepository projects and tools listed in .gitignore. Instead of being ignored, methinks they should be listed as submodules in .gitmodules: [submodule "tools/clang"] path = tools/clang url = ../clang.git [submodule "projects/compiler-rt"] path = projects/compiler-rt url = ../compiler-rt.git [submodule

On 27 June 2016 at 01:20, Matthias Braun <matze at braunis.de> wrote: > I really liked the the solution proposed earlier in this thread: Do nothing server side, but instead use > `git rev-list --count master` on the client side (which takes 0.9s on my machine) to get the number of the commit. So nothing to do on the ID part IMO. Mehdi replied to this proposal: "it does not help

james woodyatt <jhw at conjury.org> writes: > p.s. The Mercurial subrepositories feature is loads better than git > submodules and it's built into the tool. But never mind that. Just go > with Git and don't look back. Nobody ever got fired for buying from > the market leader. I don't use submodules enough to be a good juge, but my understanding is that Git's

So, It's been a while and the GitHub thread is officially dead, so I'll propose a development methodology based on the feedback from that thread. This is not *my* view, but all that was discussed in the threads. My objective is to form an official proposal to use Git as our main repository, overcoming all the problems we currently have without creating many others. In the end, I think

> On May 31, 2016, at 1:42 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote: >>> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev >>>