threads / bug / 29801

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

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

## tl;dr

3 messages between Mar 1, 2012 and Mar 1, 2012.

replies: 2people: 2as markdown or json

Luiz-Otavio Zorzella· Mar 1, 2012, 18:47 UTC · lore

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
Junio C Hamano· Mar 1, 2012, 19:45 UTC · re: Luiz-Otavio Zorzella · lore

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

Luiz-Otavio Zorzella <zorzella@gmail.com> writes:
Show 9 quoted lines
> $ 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;
+ }
Junio C Hamano· Mar 1, 2012, 20:18 UTC · re: Junio C Hamano · lore

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

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

← back to recent threads