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

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

[Luiz-Otavio Zorzella]

I'm having problems with running commands like "git rebase -i HEAD~40"
in my codebase. With git's own git repo, and I got a different error,
but I think it's related: I start with a clean tree and issue a no-op
git rebase which fails.

$ git --version
git version 1.7.7.3

$ git clone git://github.com/gitster/git.git
Cloning into 'git'...
remote: Counting objects: 129018, done.
remote: Compressing objects: 100% (41859/41859), done.
remote: Total 129018 (delta 94779), reused 118799 (delta 85455)
Receiving objects: 100% (129018/129018), 28.21 MiB | 252 KiB/s, done.
Resolving deltas: 100% (94779/94779), done.

$ cd git

$ git checkout -b blow
Switched to a new branch 'blow'

$ git branch
* blow
  master

$ 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

******************************************

Zorzella

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

[Junio C Hamano]

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.

A conflict resolution to replay that particular commit to flatten a recent
history might look like this, but it depends on where in the history you
start the rebase from.

diff --cc cache.h
index 3a8e125,24732e6..0000000
--- a/cache.h
+++ b/cache.h
@@@ -1177,7 -1176,7 +1177,8 @@@ extern void setup_pager(void)
  extern const char *pager_program;
  extern int pager_in_use(void);
  extern int pager_use_color;
 +extern int term_columns(void);
+ extern int decimal_width(int);
  
  extern const char *editor_program;
  extern const char *askpass_program;
diff --cc pager.c
index b790967,96c07ba..0000000
--- a/pager.c
+++ b/pager.c
@@@ -118,32 -112,13 +118,44 @@@ int pager_in_use(void
  }
  
  /*
 + * Return cached value (if set) or $COLUMNS environment variable (if
 + * set and positive) or ioctl(1, TIOCGWINSZ).ws_col (if positive),
 + * and default to 80 if all else fails.
 + */
 +int term_columns(void)
 +{
 +	static int term_columns_at_startup;
 +
 +	char *col_string;
 +	int n_cols;
 +
 +	if (term_columns_at_startup)
 +		return term_columns_at_startup;
 +
 +	term_columns_at_startup = 80;
 +
 +	col_string = getenv("COLUMNS");
 +	if (col_string && (n_cols = atoi(col_string)) > 0)
 +		term_columns_at_startup = n_cols;
 +#ifdef TIOCGWINSZ
 +	else {
 +		struct winsize ws;
 +		if (!ioctl(1, TIOCGWINSZ, &ws) && ws.ws_col)
 +			term_columns_at_startup = ws.ws_col;
 +	}
 +#endif
 +
 +	return term_columns_at_startup;
 +}
++
++/*
+  * How many columns do we need to show this number in decimal?
+  */
+ int decimal_width(int number)
+ {
+ 	int i, width;
+ 
+ 	for (width = 1, i = 10; i <= number; width++)
+ 		i *= 10;
+ 	return width;
+ }

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

[Junio C Hamano]

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

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