Usage of pull rebasing and merges

[David Jarvie]

On Tue, February 8, 2011 9:08 am, Ben Cooksley wrote:
> On Tue, Feb 8, 2011 at 9:49 PM, Sebastian Trüg <trueg at 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)?

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm