I realise that llvm trunk can move fairly quickly.
So my original, but brief, suggestion was to merge the current set of
approved patches together rather than attempting them one at a time.
Build on a set of fast smoke test bots. If something breaks, it should be
possible to bisect it to reject a P
https://help.github.com/articles/checking-out-pull-requests-locally/
Script a bot to scrape the patches and post to phabricator?
On Fri, 1 Feb 2019 at 04:22, Roman Lebedev via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev
> wrote:
> >
> >
[Armchair observer...]
If any merges are allowed, they should be rare, have recent parent commits,
or the history graph becomes useless.
4. Each reviewed bug / feature must be rebased onto the current "known
good" commit, merged into a "probably good" commit, tested by build bots,
and only then p
Very few operations search for commit objects by reading every single
commit file. Most operations that read commit objects already know what
they are looking for based on their hash. Plus, over time commit objects
are packed into well indexed archive files, so the total number of commits
stored in
On Fri, Jun 3, 2016 at 1:18 AM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> The issues that were raised:
>
> * Co-dependent patches already break buildbots, but the sequential ID
> helps us identify and ignore. They will continue to break, even if we
> use git sub-modules, s
