Junio C Hamano <gitster@xxxxxxxxx> writes:
> Luiz-Otavio Zorzella <zorzella@xxxxxxxxx> 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'.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html