From: Joshua Jensen Date: Sat, 28 Aug 2010 03:13:03 GMT Subject: Re: git pull --rebase differs in behavior from git fetch + git rebase Message-ID: <4C787EBF.7010802@workspacewhiz.com> In-Reply-To: ----- Original Message ----- From: Elijah Newren Date: 8/27/2010 8:40 PM > On Fri, Aug 27, 2010 at 8:06 PM, Joshua Jensen > wrote: >> Okay, there is _not_ a problem with the patch in 1.7.2.2 for the "broken" >> repository I have in front of me right now, but I wish I hadn't trashed the >> other broken repository someone else had. :( As it turns out, the other broken repository exists still, but it will be Monday before I can test against the 1.7.2.2 change. >> Sorry for causing an issue, but I definitely appreciate the fix already >> being available. > Not a problem; it's totally understandable. Believe me, I had a whole > bunch of similar problems when trying to deal with this bug when > people were hitting it at work (e.g. trying to duplicate by cloning, > which never worked since the bug depended on reflog state). Fortunately, I've worked with Git long enough now that I knew to direct copy the .git folder to the new location, 'git reset --hard' to get the files back, and hopefully then be in the same state. > In any event, I'm glad it's working for you now. :-) Me, too. Now, if only 'git rebase --preserve-merges' would work all the time and could be the default. (I have instances where a topic branch is merged back to master with --no-ff to generate the merge commit, an attempt is made to push but new commits have been added from others, so a pull --rebase is performed and ends up replaying the merge linearly... no merge commit... oh, well.) Take care. Josh