Re: [PATCH] rebase --merge: fix for rebasing more than 7 commits.
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jun 24, 2006, 07:09 UTC
- Message-ID
- <7vac83114g.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <20060622110941.GA32261@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
Show 13 quoted lines
> Junio C Hamano <junkio@cox.net> wrote: >> Junio C Hamano <junkio@cox.net> writes: >> >> > * I wanted to raise my confidence level in the new rebase --merge >> > code, so I did a little exercise which resulted in finding this >> > buglet. >> >... >> > So the exercise went like this: >> >... >> > With this fix, the above works beautifully. I am reasonably >> > happy with this shiny new toy. Good job, Eric! and thanks. > > :) Thanks for the extra QA and fix.
Another thing I noticed is while rebasing onto the mainline that has accepted a few of the patches from the topic. The original rebase with "git am -3" logic notices that the patch has already been applied and drops that commit, which is rather nice, but the new "rebase --merge" logic barfs when git-commit notices there is nothing to commit. I think you could before calling git-commit check if the git-merge-$strategy gave you the tree identical to the HEAD tree, and simply skip it (maybe after giving the user "patch already applied"message).