Tim Northover via llvm-dev
2018-Nov-16 00:25 UTC
[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo
On Fri, 16 Nov 2018 at 00:09, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote:> The original svn has atomic commits across all projects. It would be crazy to use a git version that doesn't duplicate that.I thought someone found that only a tiny fraction of commits actually made use of that. It's definitely not something anyone can rely on, so I'd consider it more of an added bonus of some approach than a requirement. Cheers. Tim.
Bruce Hoult via llvm-dev
2018-Nov-16 00:35 UTC
[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo
Yes, I'd expect only a tiny fraction of commits to change the interface between say, clang and llvm in an incompatible way, but where they do it's essential to get both sides at the same time if you want to to have every commit buildable for things such as bisection or incremental rebasing (as I think you do). On Thu, Nov 15, 2018 at 4:25 PM, Tim Northover <t.p.northover at gmail.com> wrote:> On Fri, 16 Nov 2018 at 00:09, Bruce Hoult via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > The original svn has atomic commits across all projects. It would be > crazy to use a git version that doesn't duplicate that. > > I thought someone found that only a tiny fraction of commits actually > made use of that. It's definitely not something anyone can rely on, so > I'd consider it more of an added bonus of some approach than a > requirement. > > Cheers. > > Tim. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181115/43d54e10/attachment.html>
Tim Northover via llvm-dev
2018-Nov-16 00:43 UTC
[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo
On Fri, 16 Nov 2018 at 00:35, Bruce Hoult <brucehoult at sifive.com> wrote:> Yes, I'd expect only a tiny fraction of commits to change the interface between say, clang and llvm in an incompatible way, but where they do it's essential to get both sides at the same time if you want to to have every commit buildable for things such as bisection or incremental rebasing (as I think you do).Sure, bisecting would be nice. but that ship sailed years ago. So few people actually commit to both repositories atomically that you're going to need to handle the general case anyway. I know I've made such changes, and only accidentally done it in sync once because "git llvm push" seems to do that. I've also encountered many non-synced commits when bisecting myself. Tim.