Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

[Rich Freeman]

On Sun, Sep 14, 2014 at 11:42 AM, hasufell <hasufell@g.o> 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