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

  ----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 8:40 PM

On Fri, Aug 27, 2010 at 8:06 PM, Joshua Jensen
[off-list ref]  wrote:

quoted

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.

quoted

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