search for: moys

greened at obbligato.org (David A. Greene) writes: > Actually git pull can sometimes get you into trouble. Probably git > fetch / git rebase is the better combination for LLVM. I don't get it. Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > greened at obbligato.org (David A. Greene) writes: > >> Actually git pull can sometimes get you into trouble. Probably git >> fetch / git rebase is the better combination for LLVM. > > I don't get it. > > Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? No. It does

On Wed, Oct 3, 2012 at 10:15 AM, Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> wrote: > Preston Briggs <preston.briggs at gmail.com> writes: >> Think about costs asymptotically; that's what matters. Calls and >> returns require constant time, just like addition and multiplication. > > Constant time, but not necessarily constant memory. > > Deep recursion

Hi, I've had problem with a program using LLVM that tried to dynamic_cast objects created in the JIT execution engine, from the native part of the program (for the curious, the program is PinaVM http://gitorious.org/pinavm/pages/Home). I've narrowed down the issue to the linkage of weak_odr and linkonce_odr symbols, used for the vtables, and that _must_ be unique for dynamic_cast to

greened at obbligato.org (David A. Greene) writes: >> b) We need a document explaining how patches are reviewed and referred >> to, what commit rules (and hooks) are in place and how this would work >> in a git world. It would be short and sweet. > > I'm not exactly sure what you're asking for. My assumption is that the > hooks in place for git are the same

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > dag at cray.com (David A. Greene) writes: > >> Jason Kim <jasonwkim at google.com> writes: >> >>> I believe git has a similar system for maintaining "branches of patches"  >> >> A pointer/tutorial on how to do this would be most welcome. > > It depends on the definition of

Hello ! I'm struggling again against lattice graprhics. ;) I'm trying to produce a conditionnal xyplot with two conditionning factors (let's say A and B). I want the levels of those factors (A1, A2, etc) to show in the margins of the lattice plot, not in the strips between the panels. A1 A2 A3 plot11 plot12 plot13 B1 plot21 plot22 plot23 B2 I managed to remove the

Hi, The link "Broken versions of GCC and other tools" on http://llvm.org/docs/ReleaseNotes.html points to #brokengcc, where it should point to http://llvm.org/docs/GettingStarted.html#brokengcc I guess. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Hi, I'm trying to port a piece of code using LLVM as a library to the latest SVN version. One difference between 2.6 and 2.7svn is that `llvm-config --cxxflags` now include -fno-rtti. Since my code does use RTTI information (in non-trivial dynamic_cast), my code can't compile with this. Same goes for -fexceptions. I've tried setting my CXXFLAGS to `llvm-config --cxxflags` -frtti

Joerg Sonnenberger <joerg at britannica.bec.de> writes: > The problem is answering the question of "do I have it or not". Linear > version numbers are much nicer for that. In the presence of branches, the version number alone doesn't answer this question, because the commit may be more recent than your HEAD, but in another branch. git branch --contains <sha1>, on

John McCall <rjmccall at apple.com> writes: >> git branch --contains <sha1>, on the other hand, will tell you. > > Of course, this doesn't actually help if you've cherry-picked commits > over to your branch (e.g. because it's a release branch). How is that different from SVN? If revision 1234 fixes a bug is some branch, and the last revision in your trunk

Anton Korobeynikov <anton at korobeynikov.info> writes: >> What options were used with git-svn init?  It certainly can support >> multiple branch/tag directories: >> >> init >>  --tags=<tags_subdir> >>  --branches=<branches_subdir> >> >>  You can specify more than one --tags and/or --branches options, in >>  case your

Thanks, I must have missed these, added. On Apr 22, 2010, at 1:28 AM, Matthieu Moy wrote: > Chris Lattner <clattner at apple.com> writes: > >> Ok, the LLVM 2.7 release notes are in near final shape. Please take >> a look and suggest improvements (or, better yet, just commit >> improvements if you have commit access): > > About the API changes, some that hit

Chris Lattner <clattner at apple.com> writes: > I really do appreciate distributed VCS, but only as staging. > Incremental development is crucial for the project and "take this git > push with 100K of code" will never be acceptable. Incremental development is probably promoted by DVCS far more than others. Your comment seems to imply that only the tip of each push is

Alexander MacDonald <alexmac at adobe.com> writes: > The topic of generation numbers has come up again recently on the git > lists and it looks like they might make it in > (http://stackoverflow.com/questions/6702821/ > git-commit-generation-numbers). Of course this isn't exactly the same > as svn because the numbers are only unique within a given branch, but > it

On Jul 23, 2011, at 4:34 AM, Matthieu Moy wrote: > Chris Lattner <clattner at apple.com> writes: > >> I really do appreciate distributed VCS, but only as staging. >> Incremental development is crucial for the project and "take this git >> push with 100K of code" will never be acceptable. > > Incremental development is probably promoted by DVCS far

> What options were used with git-svn init?  It certainly can support > multiple branch/tag directories: > > init >  --tags=<tags_subdir> >  --branches=<branches_subdir> > >  You can specify more than one --tags and/or --branches options, in >  case your Subversion repository places tags or branches under multiple >  paths. The svn repository is free to

Chris Lattner <clattner at apple.com> writes: > Ok, the LLVM 2.7 release notes are in near final shape. Please take > a look and suggest improvements (or, better yet, just commit > improvements if you have commit access): About the API changes, some that hit me when I ported some code to LLVM 2.7, and not in the release notes (I had sent a private email some time ago) : ---

greened at obbligato.org (David A. Greene) writes: >> Each clonee should do "git-svn dcommit" individually. >> (and it would be happier if you did "git pull --rebase llvm.org) > > Yep. > >> Of course, other branches may be push/pull-ed among repos. It is git! > > Does this mean that clone B can pull from clone A and vice-versa? The problem is the

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