rerere.autoupdate that wouldn't

So now I have rerere.autoupdate=true (living on the edge!), and today I rebased a branch and git did a new thing: it added the automerged file to the index like I expected.

Then git did an unexpected thing. It told me the merge had failed and it asked me to clean it up. There were no other conflicts; just this one conflict that was already automerged and added to my index.

All I had to do was 'git rebase --continue' and off it went.

But I was hoping for more. I was hoping that rebase would continue on its own and quit bothering me with these triflings.

Is this what is supposed to happen? Should I look into adding 'rerere.autoContinue=true'?

Maybe instead, the sane thing would be to add 'rerere.autoTest=make test'. Then if rerere is so worried about messing up my rebase, he can take a moment to do a build test to comfort his conscience.

Phil

Phil Hord <hordp@cisco.com> writes:

"Yes", and "Perhaps, but there may be a better alternative".

Whatever rerere did, "git merge", "git am", and friends should report the fact that the result is not just a trivial conflict-free merge, so that the user can take an appropriate action. Otherwise you will be robbing the last chance to eyeball the result from people who have been using rerere.autoupdate=true and doing so before committing.

And a better alternative to make "rerere.autoupdate" stronger may be to make the variable tri-valued, instead of adding a new variable that does not make any sense when rerere.autoupdate is not set.

Writ Junio C Hamano <gitster@pobox.com>,

Any preference on the third option-name?

I think  'False || True || Continue'

Phil