search for: superproject

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 recei...

...) is actually in line with the way I understand LLVM development policies and might be a nice addition if desired. In fact using a site like GitHub nicely automates the code review and commit process, and ensures that requests for review and commit aren't lost. On the comments about submodules/superprojects, I will agree they are slightly confusing at first, but it's primarily the people setting up the submodules that have to overcome that confusion. For en users they generally only need to care about running slightly different commands if they want to init and sync the superproject and use it to...

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

> 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 Wed, Jun 1, 2016 at 1:07 PM, Manuel Jacob via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2016-05-31 22:45, Mehdi Amini via llvm-dev wrote: > >> On May 31, 2016, at 1:31 PM, Renato Golin <renato.golin at linaro.org> >>> wrote: >>> >>> On 31 May 2016 at 21:28, Mehdi Amini <mehdi.amini at apple.com> wrote: >>>

On 30 June 2016 at 17:33, Reid Kleckner <rnk at google.com> wrote: > Agreed, the llvm-project repository can completely take on the role of the > SQL database in Renato's proposal. Hum, doing it in a separate server was suggested by the GitHub folks, so I just assumed they can't do that in the umbrella project for some reason. I'm all for using the umbrella if we can, I

...et a namespace collision b/c the module names are the same so puppet the ''repo'' type is the same and can''t be redefined. Certainly this is the right behavior but I''m kinda at a loss of how to rework things b/c of the collision. I had hoped to use git''s superprojects but it''s very hard to decree that the submodules are defaulted to a single branch. Also I like only the modules that have branched to show up in the dev modulepath, it removes question of where a module is being pulled from. I recognize that I could create a class that explicitly called...

...We've since stopped creating the tags, and gotten used to not having them. We do the 'rev-list --count' trick which mainly gets recorded as one component of the version number, and it has been working for us. I think having the number in the commit log (even if it's just for the superproject) would be preferable. You can use 'git log --grep' to find a particular rev if you need to. --paulr > > cheers, > --renato > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/lis...

On Wed, Feb 26, 2014 at 9:58 PM, Brad King <brad.king at kitware.com> wrote: > On 02/26/2014 12:43 PM, Alexey Samsonov wrote: > > Do you think it makes sense to land my ExternalProject_Add patch > > so that others can experiment with it? I can add quit with a > > fatal_error/warning if the build tree rules are generated with Ninja. > > Since it is conditional on

...n is a submodule), you might like to hear about code published this morning to make it easier to manage multiple git submodules in a shared-server environment. It''s imaginatively titled ''git-rake'', and it does Good Things like: * aggregates submodule commit logs into the superproject commit log * abbreviates output for git-status and other common commands (filters out what you don''t need to see) * ensures you don''t publish references to local-only submodule commits (which, if you haven''t done it, is painful) * intelligently synchronizes all submodules...

...Perhaps the performance is actually ok in practice, but I would be concerned about scaling with this approach as well: $ time git rev-list --count HEAD 115968 real 0m1.170s user 0m1.100s sys 0m0.064s > I think having the number in the commit log (even if it's just for the > superproject) would be preferable. You can use 'git log --grep' to > find a particular rev if you need to. Grepping every commit doesn't seem like the most scalable option either. I did a quick test on a large repo. First a grep for an identifier: $ time git log --grep <id> ... real...

...ld > be created by add_subdirectory(compiler-rt). > Probably I don't understand how CMAKE_PREFIX_PATH works. How can top-level targets from one build tree be visible in another build tree? > > If I were to use CMake's ExternalProject feature, it would be from a > top-level superproject. I would use it to manage dependencies and to > populate CMAKE_PREFIX_PATH for each dependency. CMake, Make or a > package manager, it wouldn't matter which you used for this part (I've > used Make for this). Ultimately, you want to end up with a top-level > build that perfor...

.../ \ / supermin -- -> guestfs-tools - (And this diagram doesn't even show the libguestfs-common submodule, which is shared by libguestfs, guestfs-tools and virt-v2v. If you want to test common submodule changes, you need to play with superproject patches like diff --git a/.gitmodules b/.gitmodules index 1343142128f6..7b1a84418c2b 100644 --- a/.gitmodules +++ b/.gitmodules @@ -1,3 +1,4 @@ [submodule "common"] path = common - url = https://github.com/libguestfs/libguestfs-common + url = file:///home/lacos/src/v...

...bly I don't understand how CMAKE_PREFIX_PATH works. How can > top-level > > targets from one build tree be visible in another build tree? > > > >> > >> > >> If I were to use CMake's ExternalProject feature, it would be from a > >> top-level superproject. I would use it to manage dependencies and to > >> populate CMAKE_PREFIX_PATH for each dependency. CMake, Make or a > >> package manager, it wouldn't matter which you used for this part (I've > >> used Make for this). Ultimately, you want to end up with a top-l...

On Thu, Jun 30, 2016 at 9:16 AM, James Y Knight via lldb-dev < lldb-dev at lists.llvm.org> wrote: > I don't think we should do any of that. It's too complicated -- and I > don't see the reason to even do it. > > There's a need for the "llvm-project" repository -- that's been discussed > plenty -- but where does the need for a separate