Re: Usage of pull rebasing and merges
On Tue, February 8, 2011 9: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. 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
Re: Usage of pull rebasing and merges
On Tue, Feb 08, 2011 at 09:20:55PM +1300, Ben Cooksley wrote: Do not run git pull --rebase after performing the merge, under any circumstances. ding ding ding - bingo! On Wed, Feb 02, 2011 at 10:27:02AM +0100, Oswald Buddenhagen wrote: and remember that following receipes does *not* work if you don't actually understand what you are doing - there may always be some circumstances that make it a receipe for disaster. and from experience i can tell that some people are astonishingly stubborn with ignoring signs of disaster ... guess what i meant by that? here's the first mail i wrote to the internal trolltech mailing list regarding that topic: if you are merging an upstream branch (say, 4.5 = 4.6) and afterwards the push goes wrong (because 4.6 has moved on already), then don't even *think* about using the usually strongly recommended git pull --rebase to get to an up-to-date state - it would rebase the merged 4.5 commits. there are basically two approaches: - just throw away the merge with git reset --hard HEAD~1 and redo it after git pull-ing. preferably, you should have git rerere enabled, so you won't have to repeat resolving any possible conflicts. - if you are a lazy sod, you can exceptionally use a regular git pull (at the usual cost of the merge looking particularly bizarre in gitk, etc.) also, push any proper merges asap - otherwise you might forget about them and get into the same situation as above. it's better to push out any local changes before starting an upstream merge, as otherwise you are mixing two workflows with contradicting recommendations wrt. rebasing. in case you do screw up, you should usually notice that - rebase says which commits it is processing, so you should see that something bogus is going on. then you can use git reflog and git reset --hard to the last good state - and simply start over. the great thing about git is, that every messup is undoable as long as the good state was committed at some point. of course, all this goes without saying for those who enhanced their personal horizon by going through the effort of actually understanding what rebases, etc. do. this is not an exclusive club - *you* could play with the cool guys, too. ;) guess what happened a few weeks later? yup, right: On Wed, Nov 18, 2009 at 03:33:33AM +0100, some troll wrote: Since the 4.6.0 branch was created, several very large chunks of history have been duplicated with new SHA1's and then pushed back into the 4.6 branch as a result of misguided use of git pull --rebase. let me put it that way: AAARRRGH!!! somebody here suggested that i should comment one that issue, as that's obviously what happened before here in berlin. the thing is: i already did, and there was some additional good input from olivier. people, really, how on earth do you manage to plain ignore the fact that git just rebased tens or hundreds of commits? i mean, it is several screenfuls of unexpected output! how can this not ring *all* alarm bells in *anyone*!?!?!? oh, well. i give up.
Re: [Kde-scm-interest] Re: Usage of pull rebasing and merges
On Tuesday 08 February 2011, Boudewijn Rempt wrote: On Tuesday 08 February 2011, Oswald Buddenhagen wrote: - just throw away the merge with git reset --hard HEAD~1 and redo it after git pull-ing. preferably, you should have git rerere enabled, so you won't have to repeat resolving any possible conflicts. Excuse my ignorance... But what is git rerere? These emails are a clear sign to me that we need recommended workflows of how to do things... Alex
Re: Usage of pull rebasing and merges
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
Re: Usage of pull rebasing and merges
On Dienstag 08 Februar 2011, Christoph Feck wrote: I don't want to. Not yet. But the more I read here, the more confused I get. the book Pro Git was/is very helpful for me and easy to read. However my copy from 2009 does not mention rerere yet http://progit.org/2010/03/08/rerere.html -- Wolfgang
