rerere.autoupdate that wouldn't

rerere.autoupdate that wouldn't

[Phil Hord]

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

Re: rerere.autoupdate that wouldn't

[Junio C Hamano]

Phil Hord <hordp@cisco.com> writes:

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

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

Re: rerere.autoupdate that wouldn't

[Phil Hord]

Writ Junio C Hamano <gitster@pobox.com>,
> Phil Hord <hordp@cisco.com> writes:
> 
>> Is this what is supposed to happen?  Should I look into adding
>> 'rerere.autoContinue=true'?
> 
> "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.

Any preference on the third option-name?

I think  'False || True || Continue'

Phil