Usage of pull rebasing and merges

[Sebastian Trüg]

Hi Ben,

thanks for clarifying. :)
Another point to add to my growing list of git tips.

Cheers,
Sebastian

On 02/08/2011 10: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.
> 
>>
>> 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
>