Usage of pull rebasing and merges

Ben Cooksley bcooksley at kde.org
Tue Feb 8 09:31:54 GMT 2011


On Tue, Feb 8, 2011 at 10:19 PM, David Jarvie <djarvie at 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 <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)?

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
>
>




More information about the kde-core-devel mailing list