On Tue, Feb 8, 2011 at 10:19 PM, David Jarvie <djar...@kde.org> wrote: > On Tue, February 8, 2011 9:08 am, Ben Cooksley wrote: >> On Tue, Feb 8, 2011 at 9:49 PM, Sebastian Trüg <tr...@kde.org> wrote: >>> Hi Ben, >>> >>> could you please elaborate on this. I do not understand the problem at >>> all. What is so bad about rebasing and what is wrong with the commit you >>> mention? >>> >>> Cheers, >>> Sebastian >> >> Hi Sebastian, >> >> The problem in this case isn't rebasing itself, but doing a pull >> rebase after doing a merge. >> If you do a pull rebase after a merge, then *all* the commits you just >> merged in will be rebased as part of that process. >> >> This will cause new commits to be created which has the effect of: >> - Increasing the repository size >> - Causing the commit hooks to run for those commits, repeating any >> keyword actions in the process >> >> The commit I pointed to was wrong because it was a commit which had >> been rebased from elsewhere, yet was unchanged other than it's >> metadata. > > I'd already come to the conclusion myself that merging before pull rebase > wasn't a good idea because of the likely conflicts which result, unlike > when the merge is done after the pull. But I don't understand any part of > your explanation above - why would it increase the repository size? don't > commit hooks run on EVERY commit anyway? what's wrong with the example > "wrong" commit, which did change one source line (not just metadata)?
The repository size will increase because it will have to store the metadata and other information about the commit. The commit I pointed to is wrong because it has been *duplicated* by rebase after merge. It already existed in another branch. Commit hooks run on every *new* commit only. This is why you can create a branch or tag of any repository on git.kde.org without causing a colossal flood of emails and cia notifications. > > -- > David Jarvie. > KDE developer. > KAlarm author - http://www.astrojar.org.uk/kalarm > >