[PATCH 0 of 1] Introduce backout --linear

[Gilles Moris]

On Tuesday 14 September 2010 10:49:12 pm Matt Mackall wrote:
> No, your reference to "rebase" in the description made me assume that
> your patch was based on an "hack the rebase extension" approach
> mentioned earlier.
>
> It's not a rebase.
>
> And I think so-called "linear backout" should become the default. There
> are no known advantages to the current approach and several known
> disadvantages.

Yes, "rebase" was a clumsy wording.
So, what I'm proposing:
- replace the current default (backout without option) with the new linear 
merge approach. Note that this affects the CLI compatibility. I am not too 
concerned though as I don't see the point using backout without --merge 
currently (except the first times you use it, until you stick a post-it under 
your screen "always use backout with --merge"). Also backout is usually not a 
command that you usually script.
- keep exactly the same behavior for backout --merge as a fallback to the 
previous "explicit merge" approach.
- if someone wants to restore the previous "default" behavior, just do a "hg 
update -C ." after a "hg backout --merge"

Last question about the need to commit or not after backout.
Currently the situation is:
                  tip     older
backout          no-op   no-op(1)
backout --merge  no-op   commit

no-op: already commit by backout
no-op(1): already commit by backout but needs to perform the merge manually
commit: need to commit the merge

With the new linear approach:
                  tip     older
backout          no-op   commit
backout --merge  no-op   commit

I am not a fan of auto-commit, so I am more inclined having to always commit 
explicitly. However, that would break the CLI even more, though backout shall 
be pretty rare. Advices ?

Regards.
Gilles.