Usage of pull rebasing and merges

[Ben Cooksley]

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.

>
> On 02/08/2011 09:20 AM, Ben Cooksley wrote:
>> Hi all,
>>
>> Just a word of warning, if you are going to merge two branches
>> together, make sure to run "git pull --rebase" before you conduct the
>> merge. Once you have conducted the merge, use "git pull" if you
>> encounter a non-fast forward error. Do not run "git pull --rebase"
>> after performing the merge, under any circumstances.
>>
>> If you do a "git pull --rebase" after performing a merge, then the
>> merge, as well as all the commits it pulled in will be rebased, along
>> with the attached consequences of that. This is what caused commits
>> such as http://article.gmane.org/gmane.comp.kde.cvs/1008397 to be
>> pushed.
>>
>> Regards,
>> Ben
>>
>

Regards,
Ben