search for: worktree

On Tue, Nov 13, 2012 at 6:02 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Add several .gitignore rules to various directories to ensure a clean > worktree after a default build. Hi, These gitignore lists require maintenance. Is is possible to express the same set of filenames as patterns like '*.inc' in the root gitigrore file, so that adding/removing a new generated file does not require updating gitignore? Dmitri -- main(i,j){for(i=2;...

Hi Dmitri, Dmitri Gribenko wrote: > On Tue, Nov 13, 2012 at 6:02 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> Add several .gitignore rules to various directories to ensure a clean >> worktree after a default build. > > Hi, > > These gitignore lists require maintenance. Is is possible to express > the same set of filenames as patterns like '*.inc' in the root > gitigrore file, so that adding/removing a new generated file does not > require updating gitignore...

...handra <artagnon at gmail.com> wrote: > Hi Dmitri, > > Dmitri Gribenko wrote: >> On Tue, Nov 13, 2012 at 6:02 PM, Ramkumar Ramachandra >> <artagnon at gmail.com> wrote: >>> Add several .gitignore rules to various directories to ensure a clean >>> worktree after a default build. >> >> Hi, >> >> These gitignore lists require maintenance. Is is possible to express >> the same set of filenames as patterns like '*.inc' in the root >> gitigrore file, so that adding/removing a new generated file does not >&...

> I was under the impression that in-source-tree builds were an unsupported > configuration. It's certainly strongly discouraged. I'm not fond of the > idea of making it easier, especially when there's a maintenance cost to > doing so. > Strongly discouraged, and yes, this. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Nov 13, 2012 at 12:04 PM, Eric Christopher <echristo at gmail.com> wrote: >> I was under the impression that in-source-tree builds were an unsupported >> configuration. It's certainly strongly discouraged. I'm not fond of the idea >> of making it easier, especially when there's a maintenance cost to doing so. > > Strongly discouraged, and yes,

Chandler Carruth wrote: > FWIW, if in-tree builds work for CMake, I consider that a bug and will fix it. How else am I supposed to build LLVM? I ran the toplevel configure and make script. Ram

Add several .gitignore rules to various directories to ensure a clean worktree after a default build. Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> --- Just cloned and built LLVM. This annoyed me. Here's a trivial patch. .gitignore | 10 ++++++++++ bindings/ocaml/llvm/.gitignore | 1 + docs/.gitignore...

There are huge differences between source files in the version 3.0.9 released as a tar.gz and source files in git. I would assume that the released version would correspond to the version in git but with 3.0.9 it is not like that. In 3.1.0 the released and git versions are more or less the same. So my question is, from what source files was the 3.0.9 version created? Thank you. Regards, Michal

...clang+compiler-rt+libcxx+clang-extra here", or "update all llvm subproject under this root", or "checkout this specific revision for all these" (with a monotonic number for the revision). At Linaro, we already have a set of scripts that do that. We're now moving to git worktree, and I think it's going to simplify our work considerably. But honestly, I'd rather not force anyone to use any set of scripts, and let people work directly with git, so I'd be more in favour of having a server-side solution, if at all possible. cheers, --renato

...ync.1, and rsyncd.conf.5. Here's my test steps, with the output of everything except the final diffstats omitted. $ cd /tmp $ tar xvf .../rsync-3.0.9.tar.gz $ tar xvf .../rsync-3.1.0.tar.gz $ git clone --bare git://git.samba.org/rsync.git /tmp/rsync-git-bare/ $ GIT_DIR=/tmp/rsync-git-bare git worktree add /tmp/rsync-git-3.0.9 v3.0.9 $ GIT_DIR=/tmp/rsync-git-bare git worktree add /tmp/rsync-git-3.1.0 v3.1.0 $ diff -Nuar rsync-git-3.0.9/ rsync-3.0.9/ --exclude .git --exclude-from rsync-git-3.0.9/.gitignore >rsync-git__rsync-3.0.9.diff $ diff -Nuar rsync-git-3.1.0/ rsync-3.1.0/ --exclude .git --...

> Today I *can* checkout only LLVM and Clang. On a single Git repo I can't. This is true if you s/checkout/clone/. With a single repo, you must clone (download) everything (*), but after you've done so you can use sparse checkouts to check out (create a working copy of) only llvm and clang. So you should only notice the fact that there exist things other than llvm and clang when you

On 22 July 2016 at 13:48, Piotr Padlewski via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> The build system can help, you just need to have two (sparse) checkout: one for LLVM/clang and the other for clang-tidy, and configure the build with the LLVM/clang checkout adding the clang-tidy as external. > Can you describe it more? Something like this $ git clone git at

...x 1.5 here, but the website is using 1.4.5. What's the version you're using? I can see some warnings on my side, but there could be some errors on the website, which would be the reason why they're empty. My local warnings: reading sources... [100%] yaml2obj /home/rengolin/devel/llvm/worktree/docs/llvm/docs/CommandGuide/lit.rst:64: WARNING: Duplicate explicit target name: "cmdoption-D". looking for now-outdated files... none found pickling environment... done checking consistency... done preparing documents... WARNING: search index couldn't be loaded, but not all documents...

...rt+libcxx+clang-extra here", or "update all llvm subproject under this root", or "checkout this specific revision for all these" (with a monotonic number for the revision). > > At Linaro, we already have a set of scripts that do that. We're now > moving to git worktree, and I think it's going to simplify our work > considerably. But honestly, I'd rather not force anyone to use any set > of scripts, and let people work directly with git, so I'd be more in > favour of having a server-side solution, if at all possible. Apparently I wasn't v...

...e share your concern. For reference, I ran some experiments: A `--bare` clone (just the Git database) I have of github.com/llvm/llvm-project was around ~1GB. Fetching this branch from github.com/apple/llvm-project increased it to ~1.2GB. Running `git gc --aggressive` brought it down to ~850MB. The worktree of the "master" branch is ~1GB. Adding the Git database gives ~2GB, ~2.2GB, and ~1.9GB. The diff of the proposed staging/apple branch is 3.1MB at `-U0`, 4.1MB at `-U3`, and 32MB at `-U999999` (Phabricator settings). More context We're making a major push over the next few months to...

...t;> other than llvm and clang when you first clone (download) llvm. > > So, we use that to a certain extent. > > Linaro's GCC validation uses the full checkout, then do a shallow > checkout that only has the updates. > > Our LLVM scripts, OTOH, clone all repos and use worktree for *all* > branches, and we only branch on the repos that we choose, for each > "working dir". > > Our scripts probably would need certain modifications... but it should be fine. > > But I'm not, by far, the most problematic user. > > The real problem, and...

Hi, In our CMake build system there are currently two ways of specifying which LLVM sub projects to build by setting CMake cache variables. * Setting `LLVM_ENABLE_PROJECTS` to the list of projects to enable (e.g. `-DLLVM_ENABLE_PROJECTS=clang;compiler-rt`) * Setting `LLVM_TOOL_<PROJECT>_BUILD` boolean CMake cache variables (e.g. `-DLLVM_TOOL_CLANG_BUILD=ON

...t;> - A `--bare` clone (just the Git database) I have of >> github.com/llvm/llvm-project was around ~1GB. Fetching this branch >> from github.com/apple/llvm-project increased it to ~1.2GB. Running >> `git gc --aggressive` brought it down to ~850MB. >> - The worktree of the "master" branch is ~1GB. Adding the Git >> database gives ~2GB, ~2.2GB, and ~1.9GB. >> - The diff of the proposed staging/apple branch is 3.1MB at `-U0`, >> 4.1MB at `-U3`, and 32MB at `-U999999` (Phabricator settings). >> >> >> >>...

>> 3. For many (most?) developers, changing to a monolithic git repo is a >> *bigger* workflow change than switching to separate git repos. Many >> people (and at least some downstream infrastructure) use the git >> mirrors exclusively, aside from git-svn for committing. >> >> I believe the idea is to continue to maintain the read-only independent >> git

I just got a Diffusion notification about a change of mine being reverted by Fangrui, but I'm not sure that's actually what happened and am confused and concerned. My commit was "[DebugInfo] Allow spill slots in call site parameter descriptions", and it appears in the history under two hashes: 1ee84e and 67c416. The first commit contains the actual change. The second touches