Re: git pull --rebase differs in behavior from git fetch + git rebase

[Joshua Jensen <jjensen@workspacewhiz.com>]

  ----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 8:40 PM
> On Fri, Aug 27, 2010 at 8:06 PM, Joshua Jensen
> <jjensen@workspacewhiz.com>  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