On Thursday, 19 de May de 2011 11:44:59 Stephen Kelly wrote: > Ben Cooksley wrote: > > Second you are heavily advocating rebasing. This shouldn't be done in > > public repositories as it: > > - Inflates the size of the repository. > > I thought git gc which runs periodically would mean that the repo size is > not inflated?
Correct.
> > - Requires some Git magic to recover if the branch you are currently
> > using gets force pushed.
> > - Is detected as new commits by the hooks, which if you were to
> > operate in the main repository would cause re-notification of commits.
> >
> > If you were to continue with your current workflow, then you would
> > likely need the assistance of Sysadmin everytime you wanted to merge a
> > significant feature which comprises of more than 100 commits into the
> > main repository.
>
> Do wee have any information about feature branches of 100 commits? When KDE
> developers push local branches how many commits are on them? Do we have
> numbers about that?
100-commit feature branches probably will do merges and thus cannot be
rebased.
A rebasing branch is usually done by a single developer and should have in
average up to 10 commits. 20 at the outset, then it starts to get really hard
to maintain.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
