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

From: Joshua Jensen <jjensen@workspacewhiz.com>
Date: Aug 28, 2010, 03:13 UTC
Message-ID: <4C787EBF.7010802@workspacewhiz.com>
In-Reply-To: <AANLkTimz4P3EGnZntQubL06ZqXREiDTDVk+fb9VVLDKN@mail.gmail.com>

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

Show 5 quoted lines

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

Show 6 quoted lines

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