similar to: [LLVMdev] git

On Wed, Jul 20, 2011 at 9:32 PM, Chris Lattner <clattner at apple.com> wrote: > On Jul 20, 2011, at 11:47 AM, Jakob Stoklund Olesen wrote: > > >>> If you can work with Jeffrey to come up with better instructions, that > would be great. > >>> > >>> Just make sure they are newbie-proof. > >> > >> Wouldn't it be easier at some

On Wed, Jul 20, 2011 at 09:32:03PM -0700, Chris Lattner wrote: > On Jul 20, 2011, at 11:47 AM, Jakob Stoklund Olesen wrote: > > >>> If you can work with Jeffrey to come up with better instructions, that would be great. > >>> > >>> Just make sure they are newbie-proof. > >> > >> Wouldn't it be easier at some point to move llvm.org

On Wed, Jul 20, 2011 at 10:46 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Wed, Jul 20, 2011 at 9:32 PM, Chris Lattner <clattner at apple.com> wrote: >> >> On Jul 20, 2011, at 11:47 AM, Jakob Stoklund Olesen wrote: >> >> >>> If you can work with Jeffrey to come up with better instructions, that >> >>> would be great.

Hi Mehdi, I really like your idea of having a few "projected" git repositories (i.e. capture all commits that touch llvm/ into llvm.git, all that touch clang/ to clang.git etc.). I think it should solve our problem of llvm-forks-with-downstream changes very nicely (I think we won't have to do anything, as you said). I still want to sleep on it to see if I can spot any issues.

> > 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: >>

> 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

Can anyone comment on their experiences with librarian-puppet or using git superproject with per puppet module repositories? We are in the midst of determining which route is optimal for our environment. It seems like using git superprojects would mean one less new tool for everyone to learn. What then would be the advantages of librarian-puppet? Thanks, Ryan Bowlby -- You received this

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

I'm in favor of both going to git as the source of truth, and then switching the hosting to github. Echoing everyone else, this unlocks a lot of good stuff that I won't repeat, and most of it can be handled independently from the VCS move. The major blocker I see for the move is figuring out how we want to coordinate versions between the related LLVM projects. I hear *terrible* things

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 some disvantages, but many advantages. Furthermore, not hosting our own repos would save us a lot of headaches, admin costs and timed out connections. TL;DR: GitHub + git submodules [1] could replace all the

> I'd also recommand "git pull --rebase" if the goal is to keep history > linear. Note that this has to go with a big, fat, warning, telling the > user that rebasing published history is bad. Rebase is a very good tool > to work with private history, but as soon as you've pushed it to some > place visible by other people, you should stop using it. This is

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

FYI, I'll plan on removing this subtree on Monday of next week if no one else chimes in requesting a reprieve... On Wed, Oct 28, 2009 at 5:59 PM, PyLLVM <pyllvm at gmail.com> wrote: > No objection. > I'm studying LLVM on Win32 using visual studio. > CMake works well for it. > > > On Oct 26, 7:44 am, Chandler Carruth <chandl... at google.com> wrote: >>

Hi, all, This isn''t about rspec, but this list has people whose opinions I respect. So, I''m looking for a new version control system for my local development. I was going to install subversion, but I''ve heard rumors of people using some newer ones. Thoughts? I''d like to be able to run it either locally or on a home server. If I run it off a home server, then

Sent from my iPhone > On Sep 8, 2016, at 11:08 AM, dag at cray.com wrote: > > Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> First, have you read this document: https://reviews.llvm.org/D24167 ? >> >> TLDR: The answer is no: you have to see it as it is today, i.e. a >> single SVN repo containing all the sub-projects, and “exports”

Just to be up-front, I normally work on very small projects and I am very much a non-core LLVM developer (I'm the MicroBlaze backend maintainer). However, we have had success where I work using the git branching model described in [1] and [2]. There is a git tool named "git-flow" that specifically supports this model and it seems like it might fit the LLVM development model so I

> > There is a git tool named "git-flow" that specifically supports this model > and it seems like it might fit the LLVM development model so I wanted to > point it out in case others had not seen it. Perhaps the more core > developers can comment more on its usefulness in the LLVM ecosystem. > > [1] http://nvie.com/posts/a-successful-git-branching-model/ > [2]

I have tried to read the documentation, but I was not able to find a clear solution to my problem. I run Samba 3.0.14a on a Debian system with Posix ACLs. I have a share on a file system that uses Posix ACLs, and I have two directories in that share. Both directories have default ACLs set, so that every new file (or directory) created under each directory (by Windows XP/2000 clients)

So here's a straw-man proposal for a github migration: 1. Register an official github project with the llvm foundation. 2. Setup another (read-only) mirror of llvm.org/git at this github project 3. Make sure we have ala llvm-project-submodules setup in the official account. (Optional or necessary for the buildbots?) 4. Update the buildbots to pick up updates and commits from the official git