Patchwork [1,of,3,V2] amend: allow amend of non-head when obsolete is enabled

login
register
mail settings
Submitter Pierre-Yves David
Date Dec. 29, 2012, 4:27 a.m.
Message ID <84678279bda502d901ef.1356755241@yamac.lan>
Download mbox | patch
Permalink /patch/330/
State Accepted
Commit c5bd753c5bc6c25ff4e0bfbe95c82095a476977d
Headers show

Comments

Pierre-Yves David - Dec. 29, 2012, 4:27 a.m.
# HG changeset patch
# User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
# Date 1356754640 -3600
# Node ID 84678279bda502d901eff3198553a7158e12b829
# Parent  8019f96ec4ce96f97dde775fe6f45007f29dabc3
amend: allow amend of non-head when obsolete is enabled

Obsolescence marker can represent this situation just fine. The old version is
marked as precursor of the new changeset. All its descendant becomes
"unstable".

If obsolescence is not enabled we keep aborting. This new default behavior only
apply when obsolete is enabled and is subject to future discussion and changes.
Augie Fackler - Dec. 31, 2012, 11:29 p.m.
On Dec 28, 2012, at 11:27 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:

> If obsolescence is not enabled we keep aborting. This new default behavior only
> apply when obsolete is enabled and is subject to future discussion and changes.

I'm not quite sure what this sentence means? Is the intent of this statement that the new behavior (with obsolete enabled) is subject to change? Or is the intent that the current (backwards-compatible) behavior without obsolete on is subject to change?
Augie Fackler - Dec. 31, 2012, 11:32 p.m.
On Dec 31, 2012, at 6:29 PM, Augie Fackler <raf at durin42.com> wrote:

> 
> On Dec 28, 2012, at 11:27 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> 
>> If obsolescence is not enabled we keep aborting. This new default behavior only
>> apply when obsolete is enabled and is subject to future discussion and changes.
> 
> I'm not quite sure what this sentence means? Is the intent of this statement that the new behavior (with obsolete enabled) is subject to change? Or is the intent that the current (backwards-compatible) behavior without obsolete on is subject to change?

I've queued all three of these with some English tweaks in the commit message, but I'll not push until I hear how I should understand this statement.
Pierre-Yves David - Dec. 31, 2012, 11:42 p.m.
On 1 janv. 2013, at 00:29, Augie Fackler wrote:

> 
> On Dec 28, 2012, at 11:27 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> 
>> If obsolescence is not enabled we keep aborting. This new default behavior only
>> apply when obsolete is enabled and is subject to future discussion and changes.
> 
> I'm not quite sure what this sentence means? Is the intent of this statement that the new behavior (with obsolete enabled) is subject to change?

The new behavior (with obsolete enabled) is open to change until we offer a simple way to enable it.

> Or is the intent that the current (backwards-compatible) behavior without obsolete on is subject to change?

The current behavior is firstly a limitation of the current implementation.

All this behavior will be discussed at the sprint.
Augie Fackler - Dec. 31, 2012, 11:45 p.m.
On Dec 31, 2012, at 6:42 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:

> 
> On 1 janv. 2013, at 00:29, Augie Fackler wrote:
> 
>> 
>> On Dec 28, 2012, at 11:27 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>> 
>>> If obsolescence is not enabled we keep aborting. This new default behavior only
>>> apply when obsolete is enabled and is subject to future discussion and changes.
>> 
>> I'm not quite sure what this sentence means? Is the intent of this statement that the new behavior (with obsolete enabled) is subject to change?
> 
> The new behavior (with obsolete enabled) is open to change until we offer a simple way to enable it.
> 
>> Or is the intent that the current (backwards-compatible) behavior without obsolete on is subject to change?
> 
> The current behavior is firstly a limitation of the current implementation.
> 
> All this behavior will be discussed at the sprint.

Okay - in light of that are you okay with this edit?

"""
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
"""

> 
> -- 
> Pierre-Yves
>

Patch

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -1294,11 +1294,11 @@  def commit(ui, repo, *pats, **opts):
             raise util.Abort(_('cannot amend public changesets'))
         if len(old.parents()) > 1:
             raise util.Abort(_('cannot amend merge changesets'))
         if len(repo[None].parents()) > 1:
             raise util.Abort(_('cannot amend while merging'))
-        if old.children():
+        if (not obsolete._enabled) and old.children():
             raise util.Abort(_('cannot amend changeset with children'))
 
         e = cmdutil.commiteditor
         if opts.get('force_editor'):
             e = cmdutil.commitforceeditor
diff --git a/tests/test-commit-amend.t b/tests/test-commit-amend.t
--- a/tests/test-commit-amend.t
+++ b/tests/test-commit-amend.t
@@ -456,5 +456,25 @@  Test that amend does not make it easy to
   $ hg revert -ar 14
   reverting a
   $ hg commit --amend
   $ hg id
   b99e5df575f7 (a) tip
+
+Test ui.prevent-unstable
+---------------------------------------------------------------------
+
+  $ hg up '.^'
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ echo 'b' >> a
+  $ hg log --style compact -r 'children(.)'
+  18[tip]:11   b99e5df575f7   1970-01-01 00:00 +0000   test
+    babar
+  
+  $ hg commit --amend
+  $ hg log -r 'unstable()'
+  changeset:   18:b99e5df575f7
+  branch:      a
+  parent:      11:3334b7925910
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     babar
+