Re: Bug: no-op "rebase -i" failures (easily reproduceable)

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 1, 2012, 20:18 UTC
Message-ID: <7v399sm5wr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vboogm7g3.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 23 quoted lines

> Luiz-Otavio Zorzella <zorzella@gmail.com> writes:
>
>> $ EDITOR=echo git rebase -i HEAD~40
>> /usr/local/google/z/gitblow/git/.git/rebase-merge/git-rebase-todo
>> error: could not apply ec7ff5b... make lineno_width() from blame
>> reusable for others
>>
>> When you have resolved this problem run "git rebase --continue".
>> If you would prefer to skip this patch, instead run "git rebase --skip".
>> To check out the original branch and stop rebasing run "git rebase --abort".
>> Could not apply ec7ff5b... make lineno_width() from blame reusable for others
>
> That is hardly surprising, given that you asked to flatten the history
> since the 40 commits before the tip of your history, and it is done out of
> a history that is full of merges from side branches.
>
> And it is not even an error, let alone a bug.  The command is asking you
> to resolve conflict it cannot resolve mechanically.  If you do as you are
> asked, you will do just fine.
>
> It is expected that you will see conflicts in such a rebase, because by
> attempting to flatten the history you are telling Git to replay a commit
> to a context that is different from its original context.

Just for fun, I tried this experiment to completion, starting at f051ad6 (Update draft release notes to 1.7.10, 2012-02-28)

    $ git checkout f051ad6
    $ git rebase -i HEAD~40

which pulls in 89 commits to be rebased (that is the number of commits not in HEAD~40 and in HEAD). After resolving and issuing "rebase --continue" several times [*1*], the resulting tree mostly matched the tree I started from.

An interesting thing to notice is that I just said "mostly". It misses the change made with an evil merge at 8080906 (Merge branch 'maint', 2012-02-26) that removes a couple of items out of the "fixed bugs" section in the 1.7.10 draft release notes, as they already appear in the 1.7.9.x release notes. Perhaps I should try to refrain from making these "Sync with maint, its release notes have "fixed" items that we have in 1.7.10 release notes so remove them from the latter" evil merges.

[Footnote]

*1* This is fairly easy for me to do, as my rerere database already knows most of the conflicts this rebase would see---they are the ones I resolved manually when the topics first hit 'next' or even 'pu'.