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