search for: depot_tool

...you already have to spend time running git blame multiple times to look past uninteresting commits so I'd love for you to give this feature a try and see if it helps you. Your feedback will be very valuable. Thanks, -Michael [1] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html

...ot;git-number" extension that assigns sequential ids to commits in the obvious way, and that provided some continuity with the "git-svn-id:" footers in commit messages. I'm not sure their extension is particularly reusable, though: https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/git_number.py I think for LLVM, whatever process updates the umbrella repo should add the sequential IDs to the commit message, and that will help provide continuity across the git/svn bridge. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://...

...LE_ASSERTIONS=ON -DCMAKE_BUILD_TYPE=Release >>> -DLLVM_TARGETS_TO_BUILD=X86 .. && ninja >>> instead? >> >> Do I need something special to support ninja? > > Put it onto your PATH? > e.g. you can > $ svn export http://src.chromium.org/svn/trunk/tools/depot_tools/ninja.exe > and put it into your cmake/bin That worked, and it does compile. I know basically nothing about ninja... is there a way to see what flags it passes to link.exe? ~Aaron > >> E:\llvm\compiler-rt-ninja>cmake -GNinja -DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_BUIL >> D_TYP...

...> blame multiple times to look past uninteresting commits so I'd love for you > to give this feature a try and see if it helps you. Your feedback will be > very valuable. > > Thanks, > -Michael > > [1] > https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Develope...

...> blame multiple times to look past uninteresting commits so I'd love for you > to give this feature a try and see if it helps you. Your feedback will be > very valuable. > > Thanks, > -Michael > > [1] > https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers ma...

...-DLLVM_TARGETS_TO_BUILD=X86 .. && ninja >>>>> instead? >>>> >>>> Do I need something special to support ninja? >>> >>> Put it onto your PATH? >>> e.g. you can >>> $ svn export http://src.chromium.org/svn/trunk/tools/depot_tools/ninja.exe >>> and put it into your cmake/bin >> >> That worked, and it does compile. I know basically nothing about >> ninja... is there a way to see what flags it passes to link.exe? > > I've found a way to check the linker output from the two builds, and >...

...d time running git blame multiple times to look past uninteresting commits so I'd love for you to give this feature a try and see if it helps you. Your feedback will be very valuable. > > Thanks, > -Michael > > [1] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html <https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm...

...;>>>>> instead? >>>>>> >>>>>> Do I need something special to support ninja? >>>>> >>>>> Put it onto your PATH? >>>>> e.g. you can >>>>> $ svn export http://src.chromium.org/svn/trunk/tools/depot_tools/ninja.exe >>>>> and put it into your cmake/bin >>>> >>>> That worked, and it does compile. I know basically nothing about >>>> ninja... is there a way to see what flags it passes to link.exe? >>> >>> I've found a way to check...

...uninteresting commits so I'd >> love for you to give this feature a try and see if it helps you. >> Your feedback will be very valuable. >> >> Thanks, >> -Michael >> >> [1] >> > https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html >> [9] >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> ______________________________________...

Thanks very much for all the feedback. I've tried to collect the information into a proposal for a transition plan: https://reviews.llvm.org/D59251. -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190312/8c8a6961/attachment.html>

...t; you to give this feature a try and see if it helps you. Your feedback will >>>> be very valuable. >>>> >>>> Thanks, >>>> -Michael >>>> >>>> [1] >>>> https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> >...

...#39;d love for you to give this feature a try and see if it helps you. Your feedback will be very valuable. >>>>> >>>>> Thanks, >>>>> -Michael >>>>> >>>>> [1] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>...

...t;>>>>> be very valuable. >>>>>>> >>>>>>> Thanks, >>>>>>> -Michael >>>>>>> >>>>>>> [1] >>>>>>> https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html >>>>>>> _______________________________________________ >>>>>>> LLVM Developers mailing list >>>>>>> llvm-dev at lists.llvm.org >>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo...

On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I don't think this is the right approach. > > Currently we intentionally define malloc etc without changing the > names and (when stuff works ok) the linker just links all the mem > allocator calls with calls to our RTL. This is kind of a link-time > interception. How could that work

...a try and see if it helps you. Your feedback will >>>>> be very valuable. >>>>> >>>>> Thanks, >>>>> -Michael >>>>> >>>>> [1] >>>>> https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> &...

On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Regarding a plan for conversion, I'm keen to avoid perfect being the enemy > of better. It seems a bit early to discuss conversion given there’s not consensus on a style. For example: If we imagine that over time it evolves such that 50% of the variables have > been renamed

...love for you to give this feature a try and see if it helps you. > >> Your feedback will be very valuable. > >> > >> Thanks, > >> -Michael > >> > >> [1] > >> > > > https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html > >> [9] > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> ____...

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 "id" that must be pushed into all of the sub-projects come from? This is the first I've heard of that as a thing that needs to

Now that we seem to be converging to an acceptable Git model, there was only one remaining doubt, and that's how the trigger to update a sequential ID will work. I've been in contact with GitHub folks, and this is in line with their suggestions... Given the nature of our project's repository structure, triggers in each repository can't just update their own sequential ID (like