# rerere.autoupdate that wouldn't

3 messages from 2012-03-09 to 2012-03-09. Participants: Phil Hord, Junio C Hamano.
Thread: https://gitlist.dev/t/29900

## Phil Hord, 2012-03-09 22:34

Subject: rerere.autoupdate that wouldn't
Message-ID: <4F5A8580.1010807@cisco.com>
URL: https://gitlist.dev/e/4F5A8580.1010807%40cisco.com

```
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

```

## Junio C Hamano, 2012-03-09 22:46

Subject: Re: rerere.autoupdate that wouldn't
Message-ID: <7vd38l4cl5.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vd38l4cl5.fsf%40alter.siamese.dyndns.org
In-Reply-To: <4F5A8580.1010807@cisco.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.

```

## Phil Hord, 2012-03-09 22:51

Subject: Re: rerere.autoupdate that wouldn't
Message-ID: <4F5A898A.2060701@cisco.com>
URL: https://gitlist.dev/e/4F5A898A.2060701%40cisco.com
In-Reply-To: <7vd38l4cl5.fsf@alter.siamese.dyndns.org>

```
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

```