Sanjoy Das via llvm-dev
2016-Jul-21 18:03 UTC
[llvm-dev] [RFC] One or many git repositories?
FWIW, like David Chisnall, we (Azul) have a problem with rewriting history. Our LLVM fork has O(100) changes diverging from upstream (though our branching structure is simple), and keeping all of that history is important. What do people think of having one (or a set of) merge commit(s) merging in the non-llvm projects that will be part of the new monorepo? That's the only technique I can think of that will preserve history for downstream users by construction. -- Sanjoy On Thu, Jul 21, 2016 at 10:44 AM, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > > On 7/21/16 11:03 AM, C Bergström via llvm-dev wrote: >> >> Monolithic is trying to solve the wrong problem - it's that simple. >> Any discussion or attempt to coddle those who think it's necessary is >> a waste of time. #dictator > > > Christopher, > > AFAICT, you haven't explained *why* it is the wrong problem. Mind > elaborating on that? > > > Jon > > p.s: edicts, appeals to authority, and ad hominems are not useful for > discussion. Doing that, and following up with "#dictator" further solidifies > that you know your own argument is b-s.... please stop. > > -- > Jon Roelofs > jonathan at codesourcery.com > CodeSourcery / Mentor Embedded > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Sanjoy Das http://playingwithpointers.com
Justin Lebar via llvm-dev
2016-Jul-21 18:20 UTC
[llvm-dev] [RFC] One or many git repositories?
> What do people think of having one (or a set of) merge commit(s) > merging in the non-llvm projects that will be part of the new > monorepo? That's the only technique I can think of that will preserve > history for downstream users by construction.This would solve the problem of importing history. But if we did it this way, you'd be unable to check out versions of the complete repo from before the merge date. So you'd be unable to bisect back before the merge date, for example. I think the umbrella repo might be a better solution than one which had that property. I don't know if there's a way to allow checkouts of everything from before the merge date while also making the custom branch merge to the monolithic repository as trivial as "git merge". I think it may depend on git's handling of file renames, and if so...I am not too hopeful. :) For at least David's branches, I think it would be really cool if we could merge the llvm and clang branches into a single branch with correct history. We wouldn't be able to do that if we used git merge to build the monorepo out of its constituent pieces. On Thu, Jul 21, 2016 at 11:03 AM, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote:> FWIW, like David Chisnall, we (Azul) have a problem with rewriting > history. Our LLVM fork has O(100) changes diverging from upstream > (though our branching structure is simple), and keeping all of that > history is important. > > What do people think of having one (or a set of) merge commit(s) > merging in the non-llvm projects that will be part of the new > monorepo? That's the only technique I can think of that will preserve > history for downstream users by construction. > > -- Sanjoy > > > On Thu, Jul 21, 2016 at 10:44 AM, Jonathan Roelofs via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> >> On 7/21/16 11:03 AM, C Bergström via llvm-dev wrote: >>> >>> Monolithic is trying to solve the wrong problem - it's that simple. >>> Any discussion or attempt to coddle those who think it's necessary is >>> a waste of time. #dictator >> >> >> Christopher, >> >> AFAICT, you haven't explained *why* it is the wrong problem. Mind >> elaborating on that? >> >> >> Jon >> >> p.s: edicts, appeals to authority, and ad hominems are not useful for >> discussion. Doing that, and following up with "#dictator" further solidifies >> that you know your own argument is b-s.... please stop. >> >> -- >> Jon Roelofs >> jonathan at codesourcery.com >> CodeSourcery / Mentor Embedded >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Sanjoy Das > http://playingwithpointers.com > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Mehdi Amini via llvm-dev
2016-Jul-21 21:29 UTC
[llvm-dev] [RFC] One or many git repositories?
> On Jul 21, 2016, at 11:03 AM, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > FWIW, like David Chisnall, we (Azul) have a problem with rewriting > history. > Our LLVM fork has O(100) changes diverging from upstream > (though our branching structure is simple), and keeping all of that > history is important.Nobody downstream has to adopt the new structure, I believe it is possible to extract only the “llvm” commits from the new repo and rebase them on top of the existing llvm repo. This can be done on the fly by you CI, but it is also a deterministic process, i.e. you can restart from scratch anytime (assuming you have the original llvm.git repo and the new one).> > What do people think of having one (or a set of) merge commit(s) > merging in the non-llvm projects that will be part of the new > monorepo? That's the only technique I can think of that will preserve > history for downstream users by construction.I have no idea what you mean here? — Mehdi> > -- Sanjoy > > > On Thu, Jul 21, 2016 at 10:44 AM, Jonathan Roelofs via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> >> On 7/21/16 11:03 AM, C Bergström via llvm-dev wrote: >>> >>> Monolithic is trying to solve the wrong problem - it's that simple. >>> Any discussion or attempt to coddle those who think it's necessary is >>> a waste of time. #dictator >> >> >> Christopher, >> >> AFAICT, you haven't explained *why* it is the wrong problem. Mind >> elaborating on that? >> >> >> Jon >> >> p.s: edicts, appeals to authority, and ad hominems are not useful for >> discussion. Doing that, and following up with "#dictator" further solidifies >> that you know your own argument is b-s.... please stop. >> >> -- >> Jon Roelofs >> jonathan at codesourcery.com >> CodeSourcery / Mentor Embedded >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Sanjoy Das > http://playingwithpointers.com > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Mehdi Amini via llvm-dev
2016-Jul-21 21:32 UTC
[llvm-dev] [RFC] One or many git repositories?
> On Jul 21, 2016, at 2:29 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Jul 21, 2016, at 11:03 AM, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> FWIW, like David Chisnall, we (Azul) have a problem with rewriting >> history. >> Our LLVM fork has O(100) changes diverging from upstream >> (though our branching structure is simple), and keeping all of that >> history is important. > > Nobody downstream has to adopt the new structure, I believe it is possible to extract only the “llvm” commits from the new repo and rebase them on top of the existing llvm repo. > This can be done on the fly by you CI, but it is also a deterministic process, i.e. you can restart from scratch anytime (assuming you have the original llvm.git repo and the new one). > >> >> What do people think of having one (or a set of) merge commit(s) >> merging in the non-llvm projects that will be part of the new >> monorepo? That's the only technique I can think of that will preserve >> history for downstream users by construction. > > I have no idea what you mean here?I think I understand what you mean: 1) checkout the existing clang repo 2) move everything in a subdirectory “clang” 3) commit the move 4) merge this into the new “llvm-project”. 5) repeat for every single project That should preserve the hashes and avoid user to have to “extract” the subproject to merge into their own branch. Annoyingly, it breaks git log path/to/file though. — Mehdi>> >> >> >> On Thu, Jul 21, 2016 at 10:44 AM, Jonathan Roelofs via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> On 7/21/16 11:03 AM, C Bergström via llvm-dev wrote: >>>> >>>> Monolithic is trying to solve the wrong problem - it's that simple. >>>> Any discussion or attempt to coddle those who think it's necessary is >>>> a waste of time. #dictator >>> >>> >>> Christopher, >>> >>> AFAICT, you haven't explained *why* it is the wrong problem. Mind >>> elaborating on that? >>> >>> >>> Jon >>> >>> p.s: edicts, appeals to authority, and ad hominems are not useful for >>> discussion. Doing that, and following up with "#dictator" further solidifies >>> that you know your own argument is b-s.... please stop. >>> >>> -- >>> Jon Roelofs >>> jonathan at codesourcery.com >>> CodeSourcery / Mentor Embedded >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> -- >> Sanjoy Das >> http://playingwithpointers.com >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >