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.
Tim Northover via llvm-dev
2018-Nov-16 00:46 UTC
[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo
On Fri, 16 Nov 2018 at 00:43, Tim Northover <t.p.northover at gmail.com> wrote:> I've also encountered many non-synced commits when bisecting myself.Sorry, this was wildly misstated (i.e. wrong). I don't recall ever being stung by a mismatched commit (beyond having to checkout a vaguely similar revision to compile). I still think the atomicity has very limited use in practice. Tim.
Dean Michael Berris via llvm-dev
2018-Nov-19 15:27 UTC
[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo
> On 16 Nov 2018, at 11:46, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, 16 Nov 2018 at 00:43, Tim Northover <t.p.northover at gmail.com> wrote: >> I've also encountered many non-synced commits when bisecting myself. > > Sorry, this was wildly misstated (i.e. wrong). I don't recall ever > being stung by a mismatched commit (beyond having to checkout a > vaguely similar revision to compile). > > I still think the atomicity has very limited use in practice. >As someone who’s needed to work on features that span all three of clang, llvm, and compiler-rt on a regular basis, I would respectfully disagree. The need for atomic commits across these projects for XRay has been there since the beginning of the effort (sometime 2016), and we’ve been relying on this using the helper scripts on top of the prototype monorepo since it’s been a thing in the latter half of 2017. We’ve broken XRay across clang, llvm, and compiler-rt a while back and have had to revert and re-apply changes across projects leading to the repository being in intermediately broken states. I’m positive that other projects that rely on doing similar kinds of changes can vouch for the massive convenience that having atomic commits across projects on a day-to-day development and code archaeology. I’m happy to provide more specific details if necessary, but so far, just in the past few weeks I’ve been making cross-cutting atomic changes spanning llvm+compiler-rt (can be seen in the subversion history as well) using the prototype monorepo and the script(s) to do ‘git llvm push’ to do the translation from a commit in git into a single commit in subversion. This is, IMO, the key “killer feature” of having a monorepo and atomic, version-locked, cross-project changes brings to projects like XRay that span multiple LLVM projects. I can easily see this being the case for the sanitisers, lld, libcxx, clang, and potentially any combination of the projects in the monorepo. Cheers -- Dean