Re: git rebase behaviour changed?

Martin Langhoff [off-list ref] writes:

Now, I have realised that a simple mistake (merging from origin in you
scenario) would lead git-rebase to discard earlier patches during the
rebase. If you had a single commit *after* the merge, git-rebase would
have rebased that single patch, and dropped earlier patches.

It may not necessarily be a mistake.

git-rebase should refuse to run in the above scenario. Is there a
straightforward way to ask if the merge base is "shared"?

<thinking>
...
</thinking>

Sorry I am always slow but I am a bit slower than I usually am
tonight, and do not understand this part without an
illustration:

        master    1---2---3---4---5---A
                 /           /
	origin  0---6---7---B


                A = master head
                B = origin head == merge base

	rev-list B..A = 1 2 3 4 5
        rev-list A..B = 6 7

The first rev-list is "what we have but they do not".  They are
the candidates to be fed upstream.  The latter is "what they
have but we do not".  Potentially some of them are commit that
represent patches we submitted earlier upstream.

Among the first list of commit, there is #4 which is a merge.
So we reject.  Is that what you meant?  Which makes sense in
this picture (but I am a bit tired and maybe this may not apply
in a different picture).


By the way, the longer I think about this, the more I agree with
the conclusion of the earlier thread: "if you rebase, do not
merge; if you merge, do not rebase".  It is really about picking
the right workflow.

Let's say you submitted #1, #2, #3 earlier, and #3 was accepted
upstream and came back as #7, and let's further assume that we
are lucky enough that patch-id gives the same answer for
"diff-tree #2" and "diff-tree #7".  So the set of commits left
are #1, #3, and #5 (#4 is just a merge so we will not re-apply).

Now, what is the shape of the final "rebased" ancestry graph we
would want?


        master                1'--3'--5'--A'
                             /
	origin  0---6---7---B

If this is what we want, why did we make #4 merge in the first
place, I wonder.  If the workflow is based on rebase [*1*],
instead of making a merge at #4, the developer *should* have
done fetch and rebase, not merge:

        master    1---2---3
                 /
	origin  0---6---7---B

        ==>

        master                1'--3'
                             /
	origin  0---6---7---B

This would have been easier to manage at the point we discovered
#6, #7, and #B, than creating #4 merge only to discard it later.

And #5 and #A can be built on top of #3'.

        master                1'--3'--5---A
                             /
	origin  0---6---7---B


[Footnote]

*1* That is certainly easier to manage for an individual
developer than a merge based workflow.  I know it because I
operated that way for a long time back when Linus was managing
git)

On 1/17/06, Junio C Hamano [off-list ref] wrote:

Sorry I am always slow but I am a bit slower than I usually am
tonight, and do not understand this part without an
illustration:

My fault. I did have a few bits of paper here on my lap, but gmail's
textbox sucks at ascii art...

        master    1---2---3---4---5---A
                 /           /
        origin  0---6---7---B


                A = master head
                B = origin head == merge base

        rev-list B..A = 1 2 3 4 5
        rev-list A..B = 6 7

Yep, exacly the example I was thinking about.

(...)

Among the first list of commit, there is #4 which is a merge.
So we reject.  Is that what you meant?

Exactly. We refuse to reset the head and begin the rebase operation,
because it looks like operator error.

By the way, the longer I think about this, the more I agree with
the conclusion of the earlier thread: "if you rebase, do not
merge; if you merge, do not rebase".  It is really about picking
the right workflow.

Definitely. But errors and misunderstandings are frequent, and people
who haven't thought the process through or aren't that familiar with
the internals are very likely to try it.

Refusing to rebase, with a good error msg gives the user a chance to
evaluate what to do with the commits. Right now, if I read the
situation right, there's a good chance commits 1,2 and 3 will be
"lost" once the rebase is complete.

GIT won't literally lose them,  someone could run git-fsck and fish
out the dangling heads from the repo, and after a bit of spelunking
recover them, but it's suddenly a really tricky operation.

cheers,


martin