On Sun, Sep 14, 2014 at 11:42 AM, hasufell <hasuf...@gentoo.org> wrote: > Patrick Lauer: >>> Are we going to disallow merge commits and ask devs to rebase local >>> changes in order to keep the history "clean"? >> >> Is that going to be sane with our commit frequency? >> > > You have to merge or rebase anyway in case of a push conflict, so the > only difference is the method and the effect on the history. > > Currently... CVS allows you to run repoman on an outdated tree and push > broken ebuilds with repoman being happy. Git will not allow this. >
Repoman is going to be a challenge here. With cvs every package is its own private repository with its own private history and cvs only cares if there is a collision within the scope of a single file. With git your commit is against the whole tree. So, even though it is trivial to merge, independent commits against two different packages do collide and need to be rebased or merged. Repoman can run against a single package fairly quickly, so assuming we still allow that we could do a pull/rebase/repman/push workflow even if people are doing commits every few minutes. On the other hand, if you're doing a package move or eclass change or some other change that affects 300 packages, just doing the rebase might cost you a few minutes (due to actual collisions), and running repoman against the whole thing before doing a push isn't going to be practical. Somebody doing a tree-wide commit would almost certainly have to run repoman before the final rebase/merge, push that out, and then maybe do another repoman after-the-fact and maybe clean up any issues. For all intents in purposes that is what we're doing today anyway, since repoman+cvs doesn't offer any kind of tree-wide consistency guarantees unless you're checking out based on a timestamp or something like that. -- Rich
