[PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Durham Goode
# HG changeset patch
# User Durham Goode <[hidden email]>
# Date 1494372571 25200
#      Tue May 09 16:29:31 2017 -0700
# Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
# Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
obsolete: add operation metadata to rebase/amend/histedit obsmarkers

By recording what operation created the obsmarker, we can show very intuitive
messages to the user in various UIs. For instance, log output could have
messages like "Amended as XXX" to show why a commit is old and has an 'x' on it.

     @  ac28e3  durham
    /   First commit
   |
   | o  d4afe7 durham
   | |  Second commit
   | |
   | x  8e9a5d (Amended as ac28e3)  durham
   |/   First commit
   |

diff --git a/hgext/histedit.py b/hgext/histedit.py
--- a/hgext/histedit.py
+++ b/hgext/histedit.py
@@ -1631,7 +1631,7 @@ def safecleanupnode(ui, repo, name, node
                              key=repo.changelog.rev)
         markers = [getmarker(t) for t in sortednodes]
         if markers:
-            obsolete.createmarkers(repo, markers)
+            obsolete.createmarkers(repo, markers, operation='histedit')
     else:
         return cleanupnode(ui, repo, name, nodes)
 
diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1341,7 +1341,7 @@ def clearrebased(ui, repo, state, skippe
                     succs = (repo[newrev],)
                 markers.append((repo[rev], succs))
         if markers:
-            obsolete.createmarkers(repo, markers)
+            obsolete.createmarkers(repo, markers, operation='rebase')
     else:
         rebased = [rev for rev in state if state[rev] > nullmerge]
         if rebased:
diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
--- a/mercurial/cmdutil.py
+++ b/mercurial/cmdutil.py
@@ -2740,7 +2740,7 @@ def amend(ui, repo, commitfunc, old, ext
                     if node:
                         obs.append((ctx, ()))
 
-                    obsolete.createmarkers(repo, obs)
+                    obsolete.createmarkers(repo, obs, operation='amend')
         if not createmarkers and newid != old.node():
             # Strip the intermediate commit (if there was one) and the amended
             # commit
diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
--- a/mercurial/obsolete.py
+++ b/mercurial/obsolete.py
@@ -1204,7 +1204,8 @@ def _computedivergentset(repo):
     return divergent
 
 
-def createmarkers(repo, relations, flag=0, date=None, metadata=None):
+def createmarkers(repo, relations, flag=0, date=None, metadata=None,
+                  operation=None):
     """Add obsolete markers between changesets in a repo
 
     <relations> must be an iterable of (<old>, (<new>, ...)[,{metadata}])
@@ -1225,6 +1226,8 @@ def createmarkers(repo, relations, flag=
         metadata = {}
     if 'user' not in metadata:
         metadata['user'] = repo.ui.username()
+    if operation:
+        metadata['operation'] = operation
     tr = repo.transaction('add-obsolescence-marker')
     try:
         markerargs = []
diff --git a/tests/test-histedit-obsolete.t b/tests/test-histedit-obsolete.t
--- a/tests/test-histedit-obsolete.t
+++ b/tests/test-histedit-obsolete.t
@@ -50,10 +50,10 @@ Test that histedit learns about obsolesc
   o  0:cb9a9f314b8b a
   
   $ hg debugobsolete
-  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
-  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'user': 'test'} (glob)
-  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'user': 'test'} (glob)
-  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
+  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
+  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'operation': 'amend', 'user': 'test'} (glob)
+  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
 
 With some node gone missing during the edit.
 
@@ -80,14 +80,14 @@ With some node gone missing during the e
   o  0:cb9a9f314b8b a
   
   $ hg debugobsolete
-  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
-  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'user': 'test'} (glob)
-  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'user': 'test'} (glob)
-  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
-  76f72745eac0643d16530e56e2f86e36e40631f1 2ca853e48edbd6453a0674dc0fe28a0974c51b9c 0 (*) {'user': 'test'} (glob)
-  2ca853e48edbd6453a0674dc0fe28a0974c51b9c aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'user': 'test'} (glob)
-  49d44ab2be1b67a79127568a67c9c99430633b48 273c1f3b86267ed3ec684bb13af1fa4d6ba56e02 0 (*) {'user': 'test'} (glob)
-  46abc7c4d8738e8563e577f7889e1b6db3da4199 aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'user': 'test'} (glob)
+  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
+  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'operation': 'amend', 'user': 'test'} (glob)
+  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  76f72745eac0643d16530e56e2f86e36e40631f1 2ca853e48edbd6453a0674dc0fe28a0974c51b9c 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
+  2ca853e48edbd6453a0674dc0fe28a0974c51b9c aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
+  49d44ab2be1b67a79127568a67c9c99430633b48 273c1f3b86267ed3ec684bb13af1fa4d6ba56e02 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  46abc7c4d8738e8563e577f7889e1b6db3da4199 aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
   $ cd ..
 
 Base setup for the rest of the testing
@@ -170,13 +170,13 @@ Base setup for the rest of the testing
   o  0:cb9a9f314b8b a
   
   $ hg debugobsolete
-  96e494a2d553dd05902ba1cee1d94d4cb7b8faed 0 {b346ab9a313db8537ecf96fca3ca3ca984ef3bd7} (*) {'user': 'test'} (glob)
-  b558abc46d09c30f57ac31e85a8a3d64d2e906e4 0 {96e494a2d553dd05902ba1cee1d94d4cb7b8faed} (*) {'user': 'test'} (glob)
-  d2ae7f538514cd87c17547b0de4cea71fe1af9fb 0 {cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b} (*) {'user': 'test'} (glob)
-  177f92b773850b59254aa5e923436f921b55483b b346ab9a313db8537ecf96fca3ca3ca984ef3bd7 0 (*) {'user': 'test'} (glob)
-  055a42cdd88768532f9cf79daa407fc8d138de9b 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'user': 'test'} (glob)
-  e860deea161a2f77de56603b340ebbb4536308ae 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'user': 'test'} (glob)
-  652413bf663ef2a641cab26574e46d5f5a64a55a cacdfd884a9321ec4e1de275ef3949fa953a1f83 0 (*) {'user': 'test'} (glob)
+  96e494a2d553dd05902ba1cee1d94d4cb7b8faed 0 {b346ab9a313db8537ecf96fca3ca3ca984ef3bd7} (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  b558abc46d09c30f57ac31e85a8a3d64d2e906e4 0 {96e494a2d553dd05902ba1cee1d94d4cb7b8faed} (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  d2ae7f538514cd87c17547b0de4cea71fe1af9fb 0 {cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b} (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  177f92b773850b59254aa5e923436f921b55483b b346ab9a313db8537ecf96fca3ca3ca984ef3bd7 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  055a42cdd88768532f9cf79daa407fc8d138de9b 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  e860deea161a2f77de56603b340ebbb4536308ae 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
+  652413bf663ef2a641cab26574e46d5f5a64a55a cacdfd884a9321ec4e1de275ef3949fa953a1f83 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
 
 
 Ensure hidden revision does not prevent histedit
diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
--- a/tests/test-obsolete.t
+++ b/tests/test-obsolete.t
@@ -1247,15 +1247,15 @@ only a subset of those are displayed (be
   adding d
   $ hg ci --amend -m dd
   $ hg debugobsolete --index --rev "3+7"
-  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'user': 'test'} (re)
-  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'user': 'test'} (re)
+  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
+  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
   $ hg debugobsolete --index --rev "3+7" -Tjson
   [
    {
     "date": *, (glob)
     "flag": 0,
     "index": 1,
-    "metadata": {"user": "test"},
+    "metadata": {"operation": "amend", "user": "test"},
     "precnode": "6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1",
     "succnodes": ["d27fb9b066076fd921277a4b9e8b9cb48c95bc6a"]
    },
@@ -1263,7 +1263,7 @@ only a subset of those are displayed (be
     "date": *, (glob)
     "flag": 0,
     "index": 3,
-    "metadata": {"user": "test"},
+    "metadata": {"operation": "amend", "user": "test"},
     "precnode": "4715cf767440ed891755448016c2b8cf70760c30",
     "succnodes": ["7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d"]
    }
@@ -1271,14 +1271,14 @@ only a subset of those are displayed (be
 
 Test the --delete option of debugobsolete command
   $ hg debugobsolete --index
-  0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'user': 'test'} (re)
-  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'user': 'test'} (re)
-  2 1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'user': 'test'} (re)
-  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'user': 'test'} (re)
+  0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
+  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
+  2 1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
+  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
   $ hg debugobsolete --delete 1 --delete 3
   deleted 2 obsolescence markers
   $ hg debugobsolete
-  cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'user': 'test'} (re)
-  1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'user': 'test'} (re)
+  cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
+  1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
   $ cd ..
 
diff --git a/tests/test-rebase-obsolete.t b/tests/test-rebase-obsolete.t
--- a/tests/test-rebase-obsolete.t
+++ b/tests/test-rebase-obsolete.t
@@ -100,9 +100,9 @@ simple rebase
   o  0:cd010b8cd998 A
   
   $ hg debugobsolete
-  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 e4e5be0395b2cbd471ed22a26b1b6a1a0658a794 0 (*) {'user': 'test'} (glob)
-  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 2327fea05063f39961b14cb69435a9898dc9a245 0 (*) {'user': 'test'} (glob)
-  32af7686d403cf45b5d95f2d70cebea587ac806a 8eeb3c33ad33d452c89e5dcf611c347f978fb42b 0 (*) {'user': 'test'} (glob)
+  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 e4e5be0395b2cbd471ed22a26b1b6a1a0658a794 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 2327fea05063f39961b14cb69435a9898dc9a245 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  32af7686d403cf45b5d95f2d70cebea587ac806a 8eeb3c33ad33d452c89e5dcf611c347f978fb42b 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
 
 
   $ cd ..
@@ -170,9 +170,9 @@ set.
   o  0:cd010b8cd998 A
   
   $ hg debugobsolete
-  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
-  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
-  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
+  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
 
 
 More complex case where part of the rebase set were already rebased
@@ -180,10 +180,10 @@ More complex case where part of the reba
   $ hg rebase --rev 'desc(D)' --dest 'desc(H)'
   rebasing 9:08483444fef9 "D"
   $ hg debugobsolete
-  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
-  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
-  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
-  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'user': 'test'} (glob)
+  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
   $ hg log -G
   @  11:4596109a6a43 D
   |
@@ -208,12 +208,12 @@ More complex case where part of the reba
   note: not rebasing 9:08483444fef9 "D", already in destination as 11:4596109a6a43 "D"
   rebasing 10:5ae4c968c6ac "C"
   $ hg debugobsolete
-  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
-  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
-  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
-  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'user': 'test'} (glob)
-  8877864f1edb05d0e07dc4ba77b67a80a7b86672 462a34d07e599b87ea08676a449373fe4e2e1347 0 (*) {'user': 'test'} (glob)
-  5ae4c968c6aca831df823664e706c9d4aa34473d 98f6af4ee9539e14da4465128f894c274900b6e5 0 (*) {'user': 'test'} (glob)
+  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  8877864f1edb05d0e07dc4ba77b67a80a7b86672 462a34d07e599b87ea08676a449373fe4e2e1347 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  5ae4c968c6aca831df823664e706c9d4aa34473d 98f6af4ee9539e14da4465128f894c274900b6e5 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
   $ hg log --rev 'divergent()'
   $ hg log -G
   o  13:98f6af4ee953 C
@@ -349,9 +349,9 @@ collapse rebase
   $ hg id --debug -r tip
   4dc2197e807bae9817f09905b50ab288be2dbbcf tip
   $ hg debugobsolete
-  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
-  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
-  32af7686d403cf45b5d95f2d70cebea587ac806a 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
+  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  32af7686d403cf45b5d95f2d70cebea587ac806a 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
 
   $ cd ..
 
@@ -411,9 +411,9 @@ not be rebased.
   o  0:cd010b8cd998 A
   
   $ hg debugobsolete
-  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b e273c5e7d2d29df783dce9f9eaa3ac4adc69c15d 0 (*) {'user': 'test'} (glob)
-  32af7686d403cf45b5d95f2d70cebea587ac806a cf44d2f5a9f4297a62be94cbdd3dff7c7dc54258 0 (*) {'user': 'test'} (glob)
-  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 7c6027df6a99d93f461868e5433f63bde20b6dfb 0 (*) {'user': 'test'} (glob)
+  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b e273c5e7d2d29df783dce9f9eaa3ac4adc69c15d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  32af7686d403cf45b5d95f2d70cebea587ac806a cf44d2f5a9f4297a62be94cbdd3dff7c7dc54258 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
+  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 7c6027df6a99d93f461868e5433f63bde20b6dfb 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
 
 Test that rewriting leaving instability behind is allowed
 ---------------------------------------------------------------------
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Martin von Zweigbergk via Mercurial-devel
On Tue, May 9, 2017 at 4:34 PM, Durham Goode <[hidden email]> wrote:

> # HG changeset patch
> # User Durham Goode <[hidden email]>
> # Date 1494372571 25200
> #      Tue May 09 16:29:31 2017 -0700
> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>
> By recording what operation created the obsmarker, we can show very intuitive
> messages to the user in various UIs. For instance, log output could have
> messages like "Amended as XXX" to show why a commit is old and has an 'x' on it.

Nice! I had previously assumed that that information was already in
the obsmarker, but then I didn't find it in `hg debugobsolete`. I
didn't realize it would be so easy to add. Seems like an obvious
improvement. So obvious that I'm hesitating to queue it only because
it seems like it should have been proposed before. Any idea why that
hasn't happened?

>
>      @  ac28e3  durham
>     /   First commit
>    |
>    | o  d4afe7 durham
>    | |  Second commit
>    | |
>    | x  8e9a5d (Amended as ac28e3)  durham
>    |/   First commit
>    |
>
> diff --git a/hgext/histedit.py b/hgext/histedit.py
> --- a/hgext/histedit.py
> +++ b/hgext/histedit.py
> @@ -1631,7 +1631,7 @@ def safecleanupnode(ui, repo, name, node
>                               key=repo.changelog.rev)
>          markers = [getmarker(t) for t in sortednodes]
>          if markers:
> -            obsolete.createmarkers(repo, markers)
> +            obsolete.createmarkers(repo, markers, operation='histedit')
>      else:
>          return cleanupnode(ui, repo, name, nodes)
>
> diff --git a/hgext/rebase.py b/hgext/rebase.py
> --- a/hgext/rebase.py
> +++ b/hgext/rebase.py
> @@ -1341,7 +1341,7 @@ def clearrebased(ui, repo, state, skippe
>                      succs = (repo[newrev],)
>                  markers.append((repo[rev], succs))
>          if markers:
> -            obsolete.createmarkers(repo, markers)
> +            obsolete.createmarkers(repo, markers, operation='rebase')
>      else:
>          rebased = [rev for rev in state if state[rev] > nullmerge]
>          if rebased:
> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
> --- a/mercurial/cmdutil.py
> +++ b/mercurial/cmdutil.py
> @@ -2740,7 +2740,7 @@ def amend(ui, repo, commitfunc, old, ext
>                      if node:
>                          obs.append((ctx, ()))
>
> -                    obsolete.createmarkers(repo, obs)
> +                    obsolete.createmarkers(repo, obs, operation='amend')
>          if not createmarkers and newid != old.node():
>              # Strip the intermediate commit (if there was one) and the amended
>              # commit
> diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
> --- a/mercurial/obsolete.py
> +++ b/mercurial/obsolete.py
> @@ -1204,7 +1204,8 @@ def _computedivergentset(repo):
>      return divergent
>
>
> -def createmarkers(repo, relations, flag=0, date=None, metadata=None):
> +def createmarkers(repo, relations, flag=0, date=None, metadata=None,
> +                  operation=None):
>      """Add obsolete markers between changesets in a repo
>
>      <relations> must be an iterable of (<old>, (<new>, ...)[,{metadata}])
> @@ -1225,6 +1226,8 @@ def createmarkers(repo, relations, flag=
>          metadata = {}
>      if 'user' not in metadata:
>          metadata['user'] = repo.ui.username()
> +    if operation:
> +        metadata['operation'] = operation
>      tr = repo.transaction('add-obsolescence-marker')
>      try:
>          markerargs = []
> diff --git a/tests/test-histedit-obsolete.t b/tests/test-histedit-obsolete.t
> --- a/tests/test-histedit-obsolete.t
> +++ b/tests/test-histedit-obsolete.t
> @@ -50,10 +50,10 @@ Test that histedit learns about obsolesc
>    o  0:cb9a9f314b8b a
>
>    $ hg debugobsolete
> -  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
> -  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'user': 'test'} (glob)
> -  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'user': 'test'} (glob)
> -  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
> +  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
>
>  With some node gone missing during the edit.
>
> @@ -80,14 +80,14 @@ With some node gone missing during the e
>    o  0:cb9a9f314b8b a
>
>    $ hg debugobsolete
> -  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
> -  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'user': 'test'} (glob)
> -  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'user': 'test'} (glob)
> -  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
> -  76f72745eac0643d16530e56e2f86e36e40631f1 2ca853e48edbd6453a0674dc0fe28a0974c51b9c 0 (*) {'user': 'test'} (glob)
> -  2ca853e48edbd6453a0674dc0fe28a0974c51b9c aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'user': 'test'} (glob)
> -  49d44ab2be1b67a79127568a67c9c99430633b48 273c1f3b86267ed3ec684bb13af1fa4d6ba56e02 0 (*) {'user': 'test'} (glob)
> -  46abc7c4d8738e8563e577f7889e1b6db3da4199 aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'user': 'test'} (glob)
> +  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  76f72745eac0643d16530e56e2f86e36e40631f1 2ca853e48edbd6453a0674dc0fe28a0974c51b9c 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  2ca853e48edbd6453a0674dc0fe28a0974c51b9c aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  49d44ab2be1b67a79127568a67c9c99430633b48 273c1f3b86267ed3ec684bb13af1fa4d6ba56e02 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  46abc7c4d8738e8563e577f7889e1b6db3da4199 aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
>    $ cd ..
>
>  Base setup for the rest of the testing
> @@ -170,13 +170,13 @@ Base setup for the rest of the testing
>    o  0:cb9a9f314b8b a
>
>    $ hg debugobsolete
> -  96e494a2d553dd05902ba1cee1d94d4cb7b8faed 0 {b346ab9a313db8537ecf96fca3ca3ca984ef3bd7} (*) {'user': 'test'} (glob)
> -  b558abc46d09c30f57ac31e85a8a3d64d2e906e4 0 {96e494a2d553dd05902ba1cee1d94d4cb7b8faed} (*) {'user': 'test'} (glob)
> -  d2ae7f538514cd87c17547b0de4cea71fe1af9fb 0 {cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b} (*) {'user': 'test'} (glob)
> -  177f92b773850b59254aa5e923436f921b55483b b346ab9a313db8537ecf96fca3ca3ca984ef3bd7 0 (*) {'user': 'test'} (glob)
> -  055a42cdd88768532f9cf79daa407fc8d138de9b 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'user': 'test'} (glob)
> -  e860deea161a2f77de56603b340ebbb4536308ae 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'user': 'test'} (glob)
> -  652413bf663ef2a641cab26574e46d5f5a64a55a cacdfd884a9321ec4e1de275ef3949fa953a1f83 0 (*) {'user': 'test'} (glob)
> +  96e494a2d553dd05902ba1cee1d94d4cb7b8faed 0 {b346ab9a313db8537ecf96fca3ca3ca984ef3bd7} (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  b558abc46d09c30f57ac31e85a8a3d64d2e906e4 0 {96e494a2d553dd05902ba1cee1d94d4cb7b8faed} (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  d2ae7f538514cd87c17547b0de4cea71fe1af9fb 0 {cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b} (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  177f92b773850b59254aa5e923436f921b55483b b346ab9a313db8537ecf96fca3ca3ca984ef3bd7 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  055a42cdd88768532f9cf79daa407fc8d138de9b 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  e860deea161a2f77de56603b340ebbb4536308ae 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  652413bf663ef2a641cab26574e46d5f5a64a55a cacdfd884a9321ec4e1de275ef3949fa953a1f83 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
>
>
>  Ensure hidden revision does not prevent histedit
> diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
> --- a/tests/test-obsolete.t
> +++ b/tests/test-obsolete.t
> @@ -1247,15 +1247,15 @@ only a subset of those are displayed (be
>    adding d
>    $ hg ci --amend -m dd
>    $ hg debugobsolete --index --rev "3+7"
> -  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'user': 'test'} (re)
> -  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'user': 'test'} (re)
> +  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
>    $ hg debugobsolete --index --rev "3+7" -Tjson
>    [
>     {
>      "date": *, (glob)
>      "flag": 0,
>      "index": 1,
> -    "metadata": {"user": "test"},
> +    "metadata": {"operation": "amend", "user": "test"},
>      "precnode": "6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1",
>      "succnodes": ["d27fb9b066076fd921277a4b9e8b9cb48c95bc6a"]
>     },
> @@ -1263,7 +1263,7 @@ only a subset of those are displayed (be
>      "date": *, (glob)
>      "flag": 0,
>      "index": 3,
> -    "metadata": {"user": "test"},
> +    "metadata": {"operation": "amend", "user": "test"},
>      "precnode": "4715cf767440ed891755448016c2b8cf70760c30",
>      "succnodes": ["7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d"]
>     }
> @@ -1271,14 +1271,14 @@ only a subset of those are displayed (be
>
>  Test the --delete option of debugobsolete command
>    $ hg debugobsolete --index
> -  0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'user': 'test'} (re)
> -  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'user': 'test'} (re)
> -  2 1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'user': 'test'} (re)
> -  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'user': 'test'} (re)
> +  0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  2 1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
>    $ hg debugobsolete --delete 1 --delete 3
>    deleted 2 obsolescence markers
>    $ hg debugobsolete
> -  cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'user': 'test'} (re)
> -  1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'user': 'test'} (re)
> +  cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
>    $ cd ..
>
> diff --git a/tests/test-rebase-obsolete.t b/tests/test-rebase-obsolete.t
> --- a/tests/test-rebase-obsolete.t
> +++ b/tests/test-rebase-obsolete.t
> @@ -100,9 +100,9 @@ simple rebase
>    o  0:cd010b8cd998 A
>
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 e4e5be0395b2cbd471ed22a26b1b6a1a0658a794 0 (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 2327fea05063f39961b14cb69435a9898dc9a245 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 8eeb3c33ad33d452c89e5dcf611c347f978fb42b 0 (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 e4e5be0395b2cbd471ed22a26b1b6a1a0658a794 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 2327fea05063f39961b14cb69435a9898dc9a245 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 8eeb3c33ad33d452c89e5dcf611c347f978fb42b 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>
>
>    $ cd ..
> @@ -170,9 +170,9 @@ set.
>    o  0:cd010b8cd998 A
>
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
>
>
>  More complex case where part of the rebase set were already rebased
> @@ -180,10 +180,10 @@ More complex case where part of the reba
>    $ hg rebase --rev 'desc(D)' --dest 'desc(H)'
>    rebasing 9:08483444fef9 "D"
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
> -  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>    $ hg log -G
>    @  11:4596109a6a43 D
>    |
> @@ -208,12 +208,12 @@ More complex case where part of the reba
>    note: not rebasing 9:08483444fef9 "D", already in destination as 11:4596109a6a43 "D"
>    rebasing 10:5ae4c968c6ac "C"
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
> -  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'user': 'test'} (glob)
> -  8877864f1edb05d0e07dc4ba77b67a80a7b86672 462a34d07e599b87ea08676a449373fe4e2e1347 0 (*) {'user': 'test'} (glob)
> -  5ae4c968c6aca831df823664e706c9d4aa34473d 98f6af4ee9539e14da4465128f894c274900b6e5 0 (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  8877864f1edb05d0e07dc4ba77b67a80a7b86672 462a34d07e599b87ea08676a449373fe4e2e1347 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5ae4c968c6aca831df823664e706c9d4aa34473d 98f6af4ee9539e14da4465128f894c274900b6e5 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>    $ hg log --rev 'divergent()'
>    $ hg log -G
>    o  13:98f6af4ee953 C
> @@ -349,9 +349,9 @@ collapse rebase
>    $ hg id --debug -r tip
>    4dc2197e807bae9817f09905b50ab288be2dbbcf tip
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>
>    $ cd ..
>
> @@ -411,9 +411,9 @@ not be rebased.
>    o  0:cd010b8cd998 A
>
>    $ hg debugobsolete
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b e273c5e7d2d29df783dce9f9eaa3ac4adc69c15d 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a cf44d2f5a9f4297a62be94cbdd3dff7c7dc54258 0 (*) {'user': 'test'} (glob)
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 7c6027df6a99d93f461868e5433f63bde20b6dfb 0 (*) {'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b e273c5e7d2d29df783dce9f9eaa3ac4adc69c15d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a cf44d2f5a9f4297a62be94cbdd3dff7c7dc54258 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 7c6027df6a99d93f461868e5433f63bde20b6dfb 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>
>  Test that rewriting leaving instability behind is allowed
>  ---------------------------------------------------------------------
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Durham Goode


On 5/9/17 4:55 PM, Martin von Zweigbergk wrote:

> On Tue, May 9, 2017 at 4:34 PM, Durham Goode <[hidden email]> wrote:
>> # HG changeset patch
>> # User Durham Goode <[hidden email]>
>> # Date 1494372571 25200
>> #      Tue May 09 16:29:31 2017 -0700
>> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>>
>> By recording what operation created the obsmarker, we can show very intuitive
>> messages to the user in various UIs. For instance, log output could have
>> messages like "Amended as XXX" to show why a commit is old and has an 'x' on it.
>
> Nice! I had previously assumed that that information was already in
> the obsmarker, but then I didn't find it in `hg debugobsolete`. I
> didn't realize it would be so easy to add. Seems like an obvious
> improvement. So obvious that I'm hesitating to queue it only because
> it seems like it should have been proposed before. Any idea why that
> hasn't happened?

It increases the size of the obsstore a bit, since I think the metadata
key is serialized every time. If we wanted to save a few bytes, we could
use something like 'o' as the key, since this would be a common entry.
But we don't do that for 'user' and it's a common entry, so... *shrug*

This topic came up once before and Pierre-Yves had comments, so he may
have comments this time.
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Jun Wu
Excerpts from Durham Goode's message of 2017-05-09 17:07:33 -0700:

> On 5/9/17 4:55 PM, Martin von Zweigbergk wrote:
> > On Tue, May 9, 2017 at 4:34 PM, Durham Goode <[hidden email]> wrote:
> >> # HG changeset patch
> >> # User Durham Goode <[hidden email]>
> >> # Date 1494372571 25200
> >> #      Tue May 09 16:29:31 2017 -0700
> >> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
> >> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
> >> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
> >>
> >> By recording what operation created the obsmarker, we can show very intuitive
> >> messages to the user in various UIs. For instance, log output could have
> >> messages like "Amended as XXX" to show why a commit is old and has an 'x' on it.
> >
> > Nice! I had previously assumed that that information was already in
> > the obsmarker, but then I didn't find it in `hg debugobsolete`. I
> > didn't realize it would be so easy to add. Seems like an obvious
> > improvement. So obvious that I'm hesitating to queue it only because
> > it seems like it should have been proposed before. Any idea why that
> > hasn't happened?
>
> It increases the size of the obsstore a bit, since I think the metadata
> key is serialized every time. If we wanted to save a few bytes, we could
> use something like 'o' as the key, since this would be a common entry.
> But we don't do that for 'user' and it's a common entry, so... *shrug*

Another idea is to dedup all strings in obsstore. Existing metadata is also
highly repetitive.

> This topic came up once before and Pierre-Yves had comments, so he may
> have comments this time.
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Pierre-Yves David-2
In reply to this post by Durham Goode
On 05/10/2017 01:34 AM, Durham Goode wrote:
> # HG changeset patch
> # User Durham Goode <[hidden email]>
> # Date 1494372571 25200
> #      Tue May 09 16:29:31 2017 -0700
> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
> obsolete: add operation metadata to rebase/amend/histedit obsmarkers

TL;DR; Storing more information is useful, but the pre-existing plans
aims at storing slightly different data in a different way. We should
stick to it.

The idea is to use the obsmarker bitfields to store the data and record
a pre-defined set of "effects" in each markers. (eg: "content change,
message change, parent change")

For examples:

1) a `hg amend` that update the diff will create a markers recording the
"content changes".

2) a `hg amend -e` that only update he commit message will record the
"message change".

3) a `hg rebase` will record the "parent change".

4) a `hg amend` that update the message, the content and user will
record these three things (content, message and meta changes).

These data can then be used to have nice template as shown by Durham
(eg: is X is a successors of Y and the markers as some "content change"
bit, we can display "amended as Y"; if their are some parent change, we
can display "rebased as Y", if both are present "amended and rebased as Y").


The above approach as multiple advantages:

   Compact: Since we use the (existing) bitfield, the storage cost is
free (or minimal if we need to adds an extra byte of bitfield).
Accessing the data is also very cheap:

   Compoundable: We'll often needs to combine multiple markers to
reports changesets between two revisions (eg: we do not have the
intermediate revisions locally). the bit field approach makes it trivial
to compound the information. We can display display the same final
information when the same result if obtained from different path (eg:
from two markers [content change; message change] or from one markers
[content change | message change]).
   This part is important because simply using operation name makes it
quite hard to combine the information.

   UI Abstraction: since we record the "effect" information, we abstract
the command names. This makes use more agile about the actual UI. User
can use their own "hg myownrewritetool" command and still record
information useful for the other users.

I've updated the wiki[1] with the above and and updated the existing
entry in the Roadmap to point to it.

[1]
https://www.mercurial-scm.org/wiki/ChangesetEvolutionDevel#Record_types_of_operation

Beside the details of what data we store and how, there are useful
intermediate steps we can take here. The "amended as 134506abcdef"
message is nice but we won't always have the data to precisely determine
the web here (eg: old client not collecting data, old markers, etc). So
starting with a neutral "rewritten as 134506abcdef" would be useful. We
could get that first, independently of the data collection.

Such change will belong well to the evolve extension first. There are
multiple test case that can be reused, we can ship it to more user to
get feedback sooner and we'll likely adjust it regularly at the
beginning. So please submit it there. Good starting point would be the
'test-evolve-obshistory.t' file and the 'hg debugobshistory' command.

> By recording what operation created the obsmarker, we can show very intuitive
> messages to the user in various UIs. For instance, log output could have
> messages like "Amended asXXX" to show why a commit is old and has an 'x' on it.
>
>      @  ac28e3  durham
>     /   First commit
>    |
>    | o  d4afe7 durham
>    | |  Second commit
>    | |
>    | x  8e9a5d (Amended as ac28e3)  durham
>    |/   First commit
>    |
>
> diff --git a/hgext/histedit.py b/hgext/histedit.py
> --- a/hgext/histedit.py
> +++ b/hgext/histedit.py
> @@ -1631,7 +1631,7 @@ def safecleanupnode(ui, repo, name, node
>                               key=repo.changelog.rev)
>          markers = [getmarker(t) for t in sortednodes]
>          if markers:
> -            obsolete.createmarkers(repo, markers)
> +            obsolete.createmarkers(repo, markers, operation='histedit')
>      else:
>          return cleanupnode(ui, repo, name, nodes)
>
> diff --git a/hgext/rebase.py b/hgext/rebase.py
> --- a/hgext/rebase.py
> +++ b/hgext/rebase.py
> @@ -1341,7 +1341,7 @@ def clearrebased(ui, repo, state, skippe
>                      succs = (repo[newrev],)
>                  markers.append((repo[rev], succs))
>          if markers:
> -            obsolete.createmarkers(repo, markers)
> +            obsolete.createmarkers(repo, markers, operation='rebase')
>      else:
>          rebased = [rev for rev in state if state[rev] > nullmerge]
>          if rebased:
> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
> --- a/mercurial/cmdutil.py
> +++ b/mercurial/cmdutil.py
> @@ -2740,7 +2740,7 @@ def amend(ui, repo, commitfunc, old, ext
>                      if node:
>                          obs.append((ctx, ()))
>
> -                    obsolete.createmarkers(repo, obs)
> +                    obsolete.createmarkers(repo, obs, operation='amend')
>          if not createmarkers and newid != old.node():
>              # Strip the intermediate commit (if there was one) and the amended
>              # commit
> diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
> --- a/mercurial/obsolete.py
> +++ b/mercurial/obsolete.py
> @@ -1204,7 +1204,8 @@ def _computedivergentset(repo):
>      return divergent
>
>
> -def createmarkers(repo, relations, flag=0, date=None, metadata=None):
> +def createmarkers(repo, relations, flag=0, date=None, metadata=None,
> +                  operation=None):
>      """Add obsolete markers between changesets in a repo
>
>      <relations> must be an iterable of (<old>, (<new>, ...)[,{metadata}])
> @@ -1225,6 +1226,8 @@ def createmarkers(repo, relations, flag=
>          metadata = {}
>      if 'user' not in metadata:
>          metadata['user'] = repo.ui.username()
> +    if operation:
> +        metadata['operation'] = operation
>      tr = repo.transaction('add-obsolescence-marker')
>      try:
>          markerargs = []
> diff --git a/tests/test-histedit-obsolete.t b/tests/test-histedit-obsolete.t
> --- a/tests/test-histedit-obsolete.t
> +++ b/tests/test-histedit-obsolete.t
> @@ -50,10 +50,10 @@ Test that histedit learns about obsolesc
>    o  0:cb9a9f314b8b a
>
>    $ hg debugobsolete
> -  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
> -  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'user': 'test'} (glob)
> -  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'user': 'test'} (glob)
> -  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
> +  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
>
>  With some node gone missing during the edit.
>
> @@ -80,14 +80,14 @@ With some node gone missing during the e
>    o  0:cb9a9f314b8b a
>
>    $ hg debugobsolete
> -  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
> -  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'user': 'test'} (glob)
> -  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'user': 'test'} (glob)
> -  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
> -  76f72745eac0643d16530e56e2f86e36e40631f1 2ca853e48edbd6453a0674dc0fe28a0974c51b9c 0 (*) {'user': 'test'} (glob)
> -  2ca853e48edbd6453a0674dc0fe28a0974c51b9c aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'user': 'test'} (glob)
> -  49d44ab2be1b67a79127568a67c9c99430633b48 273c1f3b86267ed3ec684bb13af1fa4d6ba56e02 0 (*) {'user': 'test'} (glob)
> -  46abc7c4d8738e8563e577f7889e1b6db3da4199 aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'user': 'test'} (glob)
> +  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0 {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  1b2d564fad96311b45362f17c2aa855150efb35f 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  114f4176969ef342759a8a57e6bccefc4234829b 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  76f72745eac0643d16530e56e2f86e36e40631f1 2ca853e48edbd6453a0674dc0fe28a0974c51b9c 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  2ca853e48edbd6453a0674dc0fe28a0974c51b9c aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'operation': 'amend', 'user': 'test'} (glob)
> +  49d44ab2be1b67a79127568a67c9c99430633b48 273c1f3b86267ed3ec684bb13af1fa4d6ba56e02 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  46abc7c4d8738e8563e577f7889e1b6db3da4199 aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
>    $ cd ..
>
>  Base setup for the rest of the testing
> @@ -170,13 +170,13 @@ Base setup for the rest of the testing
>    o  0:cb9a9f314b8b a
>
>    $ hg debugobsolete
> -  96e494a2d553dd05902ba1cee1d94d4cb7b8faed 0 {b346ab9a313db8537ecf96fca3ca3ca984ef3bd7} (*) {'user': 'test'} (glob)
> -  b558abc46d09c30f57ac31e85a8a3d64d2e906e4 0 {96e494a2d553dd05902ba1cee1d94d4cb7b8faed} (*) {'user': 'test'} (glob)
> -  d2ae7f538514cd87c17547b0de4cea71fe1af9fb 0 {cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b} (*) {'user': 'test'} (glob)
> -  177f92b773850b59254aa5e923436f921b55483b b346ab9a313db8537ecf96fca3ca3ca984ef3bd7 0 (*) {'user': 'test'} (glob)
> -  055a42cdd88768532f9cf79daa407fc8d138de9b 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'user': 'test'} (glob)
> -  e860deea161a2f77de56603b340ebbb4536308ae 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'user': 'test'} (glob)
> -  652413bf663ef2a641cab26574e46d5f5a64a55a cacdfd884a9321ec4e1de275ef3949fa953a1f83 0 (*) {'user': 'test'} (glob)
> +  96e494a2d553dd05902ba1cee1d94d4cb7b8faed 0 {b346ab9a313db8537ecf96fca3ca3ca984ef3bd7} (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  b558abc46d09c30f57ac31e85a8a3d64d2e906e4 0 {96e494a2d553dd05902ba1cee1d94d4cb7b8faed} (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  d2ae7f538514cd87c17547b0de4cea71fe1af9fb 0 {cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b} (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  177f92b773850b59254aa5e923436f921b55483b b346ab9a313db8537ecf96fca3ca3ca984ef3bd7 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  055a42cdd88768532f9cf79daa407fc8d138de9b 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  e860deea161a2f77de56603b340ebbb4536308ae 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
> +  652413bf663ef2a641cab26574e46d5f5a64a55a cacdfd884a9321ec4e1de275ef3949fa953a1f83 0 (*) {'operation': 'histedit', 'user': 'test'} (glob)
>
>
>  Ensure hidden revision does not prevent histedit
> diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
> --- a/tests/test-obsolete.t
> +++ b/tests/test-obsolete.t
> @@ -1247,15 +1247,15 @@ only a subset of those are displayed (be
>    adding d
>    $ hg ci --amend -m dd
>    $ hg debugobsolete --index --rev "3+7"
> -  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'user': 'test'} (re)
> -  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'user': 'test'} (re)
> +  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
>    $ hg debugobsolete --index --rev "3+7" -Tjson
>    [
>     {
>      "date": *, (glob)
>      "flag": 0,
>      "index": 1,
> -    "metadata": {"user": "test"},
> +    "metadata": {"operation": "amend", "user": "test"},
>      "precnode": "6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1",
>      "succnodes": ["d27fb9b066076fd921277a4b9e8b9cb48c95bc6a"]
>     },
> @@ -1263,7 +1263,7 @@ only a subset of those are displayed (be
>      "date": *, (glob)
>      "flag": 0,
>      "index": 3,
> -    "metadata": {"user": "test"},
> +    "metadata": {"operation": "amend", "user": "test"},
>      "precnode": "4715cf767440ed891755448016c2b8cf70760c30",
>      "succnodes": ["7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d"]
>     }
> @@ -1271,14 +1271,14 @@ only a subset of those are displayed (be
>
>  Test the --delete option of debugobsolete command
>    $ hg debugobsolete --index
> -  0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'user': 'test'} (re)
> -  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'user': 'test'} (re)
> -  2 1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'user': 'test'} (re)
> -  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'user': 'test'} (re)
> +  0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1 d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  2 1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  3 4715cf767440ed891755448016c2b8cf70760c30 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
>    $ hg debugobsolete --delete 1 --delete 3
>    deleted 2 obsolescence markers
>    $ hg debugobsolete
> -  cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'user': 'test'} (re)
> -  1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'user': 'test'} (re)
> +  cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
> +  1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'operation': 'amend', 'user': 'test'} (re)
>    $ cd ..
>
> diff --git a/tests/test-rebase-obsolete.t b/tests/test-rebase-obsolete.t
> --- a/tests/test-rebase-obsolete.t
> +++ b/tests/test-rebase-obsolete.t
> @@ -100,9 +100,9 @@ simple rebase
>    o  0:cd010b8cd998 A
>
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 e4e5be0395b2cbd471ed22a26b1b6a1a0658a794 0 (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 2327fea05063f39961b14cb69435a9898dc9a245 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 8eeb3c33ad33d452c89e5dcf611c347f978fb42b 0 (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 e4e5be0395b2cbd471ed22a26b1b6a1a0658a794 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 2327fea05063f39961b14cb69435a9898dc9a245 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 8eeb3c33ad33d452c89e5dcf611c347f978fb42b 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>
>
>    $ cd ..
> @@ -170,9 +170,9 @@ set.
>    o  0:cd010b8cd998 A
>
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
>
>
>  More complex case where part of the rebase set were already rebased
> @@ -180,10 +180,10 @@ More complex case where part of the reba
>    $ hg rebase --rev 'desc(D)' --dest 'desc(H)'
>    rebasing 9:08483444fef9 "D"
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
> -  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>    $ hg log -G
>    @  11:4596109a6a43 D
>    |
> @@ -208,12 +208,12 @@ More complex case where part of the reba
>    note: not rebasing 9:08483444fef9 "D", already in destination as 11:4596109a6a43 "D"
>    rebasing 10:5ae4c968c6ac "C"
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
> -  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'user': 'test'} (glob)
> -  8877864f1edb05d0e07dc4ba77b67a80a7b86672 462a34d07e599b87ea08676a449373fe4e2e1347 0 (*) {'user': 'test'} (glob)
> -  5ae4c968c6aca831df823664e706c9d4aa34473d 98f6af4ee9539e14da4465128f894c274900b6e5 0 (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0 {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0 {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  08483444fef91d6224f6655ee586a65d263ad34c 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  8877864f1edb05d0e07dc4ba77b67a80a7b86672 462a34d07e599b87ea08676a449373fe4e2e1347 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5ae4c968c6aca831df823664e706c9d4aa34473d 98f6af4ee9539e14da4465128f894c274900b6e5 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>    $ hg log --rev 'divergent()'
>    $ hg log -G
>    o  13:98f6af4ee953 C
> @@ -349,9 +349,9 @@ collapse rebase
>    $ hg id --debug -r tip
>    4dc2197e807bae9817f09905b50ab288be2dbbcf tip
>    $ hg debugobsolete
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>
>    $ cd ..
>
> @@ -411,9 +411,9 @@ not be rebased.
>    o  0:cd010b8cd998 A
>
>    $ hg debugobsolete
> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b e273c5e7d2d29df783dce9f9eaa3ac4adc69c15d 0 (*) {'user': 'test'} (glob)
> -  32af7686d403cf45b5d95f2d70cebea587ac806a cf44d2f5a9f4297a62be94cbdd3dff7c7dc54258 0 (*) {'user': 'test'} (glob)
> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 7c6027df6a99d93f461868e5433f63bde20b6dfb 0 (*) {'user': 'test'} (glob)
> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b e273c5e7d2d29df783dce9f9eaa3ac4adc69c15d 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  32af7686d403cf45b5d95f2d70cebea587ac806a cf44d2f5a9f4297a62be94cbdd3dff7c7dc54258 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 7c6027df6a99d93f461868e5433f63bde20b6dfb 0 (*) {'operation': 'rebase', 'user': 'test'} (glob)
>
>  Test that rewriting leaving instability behind is allowed
>  ---------------------------------------------------------------------
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Durham Goode
On 5/10/17 3:40 AM, Pierre-Yves David wrote:

> On 05/10/2017 01:34 AM, Durham Goode wrote:
>> # HG changeset patch
>> # User Durham Goode <[hidden email]>
>> # Date 1494372571 25200
>> #      Tue May 09 16:29:31 2017 -0700
>> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>
> TL;DR; Storing more information is useful, but the pre-existing plans
> aims at storing slightly different data in a different way. We should
> stick to it.
>
> The idea is to use the obsmarker bitfields to store the data and record
> a pre-defined set of "effects" in each markers. (eg: "content change,
> message change, parent change")
>
> For examples:
>
> 1) a `hg amend` that update the diff will create a markers recording the
> "content changes".
>
> 2) a `hg amend -e` that only update he commit message will record the
> "message change".
>
> 3) a `hg rebase` will record the "parent change".
>
> 4) a `hg amend` that update the message, the content and user will
> record these three things (content, message and meta changes).
>
> These data can then be used to have nice template as shown by Durham
> (eg: is X is a successors of Y and the markers as some "content change"
> bit, we can display "amended as Y"; if their are some parent change, we
> can display "rebased as Y", if both are present "amended and rebased as
> Y").
>

While having the above data seems nice, I don't know if it justifies not
going with the current simple approach today. Otherwise we have to wait
for this large obsstore refactor, which seems like a rather big
dependency to block an important UX feature we could deliver today.

When the bit field is added in the future we can always change our
templates and messaging to use that data as well.  And if it's good
enough, we can drop the 'operation' metadata entirely, with little
compatibility issue.

> The above approach as multiple advantages:
>
>   Compact: Since we use the (existing) bitfield, the storage cost is
> free (or minimal if we need to adds an extra byte of bitfield).
> Accessing the data is also very cheap:
>
>   Compoundable: We'll often needs to combine multiple markers to reports
> changesets between two revisions (eg: we do not have the intermediate
> revisions locally). the bit field approach makes it trivial to compound
> the information. We can display display the same final information when
> the same result if obtained from different path (eg: from two markers
> [content change; message change] or from one markers [content change |
> message change]).
>   This part is important because simply using operation name makes it
> quite hard to combine the information.

Yes, if there were multiple operations we'd have to union them just as
operation='modified' or something. Not ideal, but should be an outlier case.

>   UI Abstraction: since we record the "effect" information, we abstract
> the command names. This makes use more agile about the actual UI. User
> can use their own "hg myownrewritetool" command and still record
> information useful for the other users.

I think recording the actual command the user ran is important. The goal
of showing this in the UI is to let the user know what past action
caused this commit to become a new commit, so if they run 'hg
flabbernate' it's much more useful to show them 'fblabbernated to be X'
than it is to show them 'amended to be X'. So potentially, even if we
have the bitfield data, it could still be important to record the actual
command that caused this obsmarker to be created (ex: "amended to be X
by hg flabbernate")
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Augie Fackler-2

> On May 10, 2017, at 11:45, Durham Goode <[hidden email]> wrote:
>
> On 5/10/17 3:40 AM, Pierre-Yves David wrote:
>> On 05/10/2017 01:34 AM, Durham Goode wrote:
>>> # HG changeset patch
>>> # User Durham Goode <[hidden email]>
>>> # Date 1494372571 25200
>>> #      Tue May 09 16:29:31 2017 -0700
>>> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>>> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>>> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>>
>> TL;DR; Storing more information is useful, but the pre-existing plans
>> aims at storing slightly different data in a different way. We should
>> stick to it.
>>
>> The idea is to use the obsmarker bitfields to store the data and record
>> a pre-defined set of "effects" in each markers. (eg: "content change,
>> message change, parent change")
>>
>> For examples:
>>
>> 1) a `hg amend` that update the diff will create a markers recording the
>> "content changes".
>>
>> 2) a `hg amend -e` that only update he commit message will record the
>> "message change".
>>
>> 3) a `hg rebase` will record the "parent change".
>>
>> 4) a `hg amend` that update the message, the content and user will
>> record these three things (content, message and meta changes).
>>
>> These data can then be used to have nice template as shown by Durham
>> (eg: is X is a successors of Y and the markers as some "content change"
>> bit, we can display "amended as Y"; if their are some parent change, we
>> can display "rebased as Y", if both are present "amended and rebased as
>> Y").
>>
>
> While having the above data seems nice, I don't know if it justifies not going with the current simple approach today. Otherwise we have to wait for this large obsstore refactor, which seems like a rather big dependency to block an important UX feature we could deliver today.

I agree. This is something that we've observed would be a big help to our git refugees at Google. I'd like to move forward with putting it in extra as a string.

> When the bit field is added in the future we can always change our templates and messaging to use that data as well.  And if it's good enough, we can drop the 'operation' metadata entirely, with little compatibility issue.

Yep. Sounds good to me.

>
>> The above approach as multiple advantages:
>>
>>  Compact: Since we use the (existing) bitfield, the storage cost is
>> free (or minimal if we need to adds an extra byte of bitfield).
>> Accessing the data is also very cheap:
>>
>>  Compoundable: We'll often needs to combine multiple markers to reports
>> changesets between two revisions (eg: we do not have the intermediate
>> revisions locally). the bit field approach makes it trivial to compound
>> the information. We can display display the same final information when
>> the same result if obtained from different path (eg: from two markers
>> [content change; message change] or from one markers [content change |
>> message change]).
>>  This part is important because simply using operation name makes it
>> quite hard to combine the information.
>
> Yes, if there were multiple operations we'd have to union them just as operation='modified' or something. Not ideal, but should be an outlier case.
>
>>  UI Abstraction: since we record the "effect" information, we abstract
>> the command names. This makes use more agile about the actual UI. User
>> can use their own "hg myownrewritetool" command and still record
>> information useful for the other users.
>
> I think recording the actual command the user ran is important. The goal of showing this in the UI is to let the user know what past action caused this commit to become a new commit, so if they run 'hg flabbernate' it's much more useful to show them 'fblabbernated to be X' than it is to show them 'amended to be X'. So potentially, even if we have the bitfield data, it could still be important to record the actual command that caused this obsmarker to be created (ex: "amended to be X by hg flabbernate")

I 100% agree here. The command verbs should map obviously onto the verbs that are saved in the obsmarkers.

AF

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Martin von Zweigbergk via Mercurial-devel
In reply to this post by Durham Goode
On Wed, May 10, 2017 at 8:45 AM, Durham Goode <[hidden email]> wrote:

> On 5/10/17 3:40 AM, Pierre-Yves David wrote:
>>
>> On 05/10/2017 01:34 AM, Durham Goode wrote:
>>>
>>> # HG changeset patch
>>> # User Durham Goode <[hidden email]>
>>> # Date 1494372571 25200
>>> #      Tue May 09 16:29:31 2017 -0700
>>> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>>> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>>> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>>
>>
>> TL;DR; Storing more information is useful, but the pre-existing plans
>> aims at storing slightly different data in a different way. We should
>> stick to it.
>>
>> The idea is to use the obsmarker bitfields to store the data and record
>> a pre-defined set of "effects" in each markers. (eg: "content change,
>> message change, parent change")
>>
>> For examples:
>>
>> 1) a `hg amend` that update the diff will create a markers recording the
>> "content changes".
>>
>> 2) a `hg amend -e` that only update he commit message will record the
>> "message change".
>>
>> 3) a `hg rebase` will record the "parent change".
>>
>> 4) a `hg amend` that update the message, the content and user will
>> record these three things (content, message and meta changes).
>>
>> These data can then be used to have nice template as shown by Durham
>> (eg: is X is a successors of Y and the markers as some "content change"
>> bit, we can display "amended as Y"; if their are some parent change, we
>> can display "rebased as Y", if both are present "amended and rebased as
>> Y").
>>
>
> While having the above data seems nice, I don't know if it justifies not
> going with the current simple approach today. Otherwise we have to wait for
> this large obsstore refactor, which seems like a rather big dependency to
> block an important UX feature we could deliver today.
>
> When the bit field is added in the future we can always change our templates
> and messaging to use that data as well.  And if it's good enough, we can
> drop the 'operation' metadata entirely, with little compatibility issue.
>
>> The above approach as multiple advantages:
>>
>>   Compact: Since we use the (existing) bitfield, the storage cost is
>> free (or minimal if we need to adds an extra byte of bitfield).
>> Accessing the data is also very cheap:
>>
>>   Compoundable: We'll often needs to combine multiple markers to reports
>> changesets between two revisions (eg: we do not have the intermediate
>> revisions locally). the bit field approach makes it trivial to compound
>> the information. We can display display the same final information when
>> the same result if obtained from different path (eg: from two markers
>> [content change; message change] or from one markers [content change |
>> message change]).
>>   This part is important because simply using operation name makes it
>> quite hard to combine the information.
>
>
> Yes, if there were multiple operations we'd have to union them just as
> operation='modified' or something. Not ideal, but should be an outlier case.

With our setup internally, it's not really an outlier case. We tag
revisions that are sent for code review and leave the tags until next
time the change is sent for review. There can thus be many amends and
rebases between the revision sent for review and the current latest
revision. I'm not sure what a good way of presenting that to the user
would be.

>
>>   UI Abstraction: since we record the "effect" information, we abstract
>> the command names. This makes use more agile about the actual UI. User
>> can use their own "hg myownrewritetool" command and still record
>> information useful for the other users.
>
>
> I think recording the actual command the user ran is important. The goal of
> showing this in the UI is to let the user know what past action caused this
> commit to become a new commit, so if they run 'hg flabbernate' it's much
> more useful to show them 'fblabbernated to be X' than it is to show them
> 'amended to be X'. So potentially, even if we have the bitfield data, it
> could still be important to record the actual command that caused this
> obsmarker to be created (ex: "amended to be X by hg flabbernate")
>
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Augie Fackler-2

> On May 10, 2017, at 11:52, Martin von Zweigbergk <[hidden email]> wrote:
>
>>> Compoundable: We'll often needs to combine multiple markers to reports
>>> changesets between two revisions (eg: we do not have the intermediate
>>> revisions locally). the bit field approach makes it trivial to compound
>>> the information. We can display display the same final information when
>>> the same result if obtained from different path (eg: from two markers
>>> [content change; message change] or from one markers [content change |
>>> message change]).
>>>  This part is important because simply using operation name makes it
>>> quite hard to combine the information.
>>
>>
>> Yes, if there were multiple operations we'd have to union them just as
>> operation='modified' or something. Not ideal, but should be an outlier case.
>
> With our setup internally, it's not really an outlier case. We tag
> revisions that are sent for code review and leave the tags until next
> time the change is sent for review. There can thus be many amends and
> rebases between the revision sent for review and the current latest
> revision. I'm not sure what a good way of presenting that to the user
> would be.

I think the common case is rebased and amended - couldn't we observe the list of actions in the list and emit something like

deadbeef rebased, amended to beefdead

in `hg log` output?

I'd rather not let the perfect be the enemy of the good here - we can at least get the data recorded and start experimenting with ways of operating on it. It's already missing from countless thousands of markers, so we'll never be able to assume it exists, so I feel like we might as well start recording it and see if we need to iterate on how we're recording it from there.
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Durham Goode
In reply to this post by Martin von Zweigbergk via Mercurial-devel


On 5/10/17 8:52 AM, Martin von Zweigbergk wrote:

> On Wed, May 10, 2017 at 8:45 AM, Durham Goode <[hidden email]> wrote:
>> On 5/10/17 3:40 AM, Pierre-Yves David wrote:
>>>
>>>   Compoundable: We'll often needs to combine multiple markers to reports
>>> changesets between two revisions (eg: we do not have the intermediate
>>> revisions locally). the bit field approach makes it trivial to compound
>>> the information. We can display display the same final information when
>>> the same result if obtained from different path (eg: from two markers
>>> [content change; message change] or from one markers [content change |
>>> message change]).
>>>   This part is important because simply using operation name makes it
>>> quite hard to combine the information.
>>
>>
>> Yes, if there were multiple operations we'd have to union them just as
>> operation='modified' or something. Not ideal, but should be an outlier case.
>
> With our setup internally, it's not really an outlier case. We tag
> revisions that are sent for code review and leave the tags until next
> time the change is sent for review. There can thus be many amends and
> rebases between the revision sent for review and the current latest
> revision. I'm not sure what a good way of presenting that to the user
> would be.

Ah, yes. I was thinking about multiple markers between the same nodes,
but the chain of commits that are not all visible is a common case (and
is obviously what Pierre-Yves was talking about when I read closer).

Yes, this case wouldn't be well handled by the operation string
solution.  One solution we've had internally is to have a smartlog
output that shows all the successors to a node.  So you can see "X was
amended to be Y", "Y was rebased to be Z", "Z was landed as V". It makes
it very easy to visually traverse the history of a node and could allow
a user to dig in to a generic "X was modified to be V" unioned-message.
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Martin von Zweigbergk via Mercurial-devel
In reply to this post by Augie Fackler-2
On Wed, May 10, 2017 at 8:57 AM, Augie Fackler <[hidden email]> wrote:

>
>> On May 10, 2017, at 11:52, Martin von Zweigbergk <[hidden email]> wrote:
>>
>>>> Compoundable: We'll often needs to combine multiple markers to reports
>>>> changesets between two revisions (eg: we do not have the intermediate
>>>> revisions locally). the bit field approach makes it trivial to compound
>>>> the information. We can display display the same final information when
>>>> the same result if obtained from different path (eg: from two markers
>>>> [content change; message change] or from one markers [content change |
>>>> message change]).
>>>>  This part is important because simply using operation name makes it
>>>> quite hard to combine the information.
>>>
>>>
>>> Yes, if there were multiple operations we'd have to union them just as
>>> operation='modified' or something. Not ideal, but should be an outlier case.
>>
>> With our setup internally, it's not really an outlier case. We tag
>> revisions that are sent for code review and leave the tags until next
>> time the change is sent for review. There can thus be many amends and
>> rebases between the revision sent for review and the current latest
>> revision. I'm not sure what a good way of presenting that to the user
>> would be.
>
> I think the common case is rebased and amended - couldn't we observe the list of actions in the list and emit something like
>
> deadbeef rebased, amended to beefdead
>
> in `hg log` output?
>
> I'd rather not let the perfect be the enemy of the good here - we can at least get the data recorded and start experimenting with ways of operating on it. It's already missing from countless thousands of markers, so we'll never be able to assume it exists, so I feel like we might as well start recording it and see if we need to iterate on how we're recording it from there.

I agree. I didn't mean to use it as an argument against Durham's
patch, just something to think about. And I think agree with you about
how to do it. My initial thought was also to keep a set of all
distinct operations along the chain.
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Sean Farley-3
In reply to this post by Augie Fackler-2
Augie Fackler <[hidden email]> writes:

>> On May 10, 2017, at 11:45, Durham Goode <[hidden email]> wrote:
>>
>> On 5/10/17 3:40 AM, Pierre-Yves David wrote:
>>> On 05/10/2017 01:34 AM, Durham Goode wrote:
>>>> # HG changeset patch
>>>> # User Durham Goode <[hidden email]>
>>>> # Date 1494372571 25200
>>>> #      Tue May 09 16:29:31 2017 -0700
>>>> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>>>> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>>>> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>>>
>>> TL;DR; Storing more information is useful, but the pre-existing plans
>>> aims at storing slightly different data in a different way. We should
>>> stick to it.
>>>
>>> The idea is to use the obsmarker bitfields to store the data and record
>>> a pre-defined set of "effects" in each markers. (eg: "content change,
>>> message change, parent change")
>>>
>>> For examples:
>>>
>>> 1) a `hg amend` that update the diff will create a markers recording the
>>> "content changes".
>>>
>>> 2) a `hg amend -e` that only update he commit message will record the
>>> "message change".
>>>
>>> 3) a `hg rebase` will record the "parent change".
>>>
>>> 4) a `hg amend` that update the message, the content and user will
>>> record these three things (content, message and meta changes).
>>>
>>> These data can then be used to have nice template as shown by Durham
>>> (eg: is X is a successors of Y and the markers as some "content change"
>>> bit, we can display "amended as Y"; if their are some parent change, we
>>> can display "rebased as Y", if both are present "amended and rebased as
>>> Y").
>>>
>>
>> While having the above data seems nice, I don't know if it justifies not going with the current simple approach today. Otherwise we have to wait for this large obsstore refactor, which seems like a rather big dependency to block an important UX feature we could deliver today.
>
> I agree. This is something that we've observed would be a big help to our git refugees at Google. I'd like to move forward with putting it in extra as a string.
>
>> When the bit field is added in the future we can always change our templates and messaging to use that data as well.  And if it's good enough, we can drop the 'operation' metadata entirely, with little compatibility issue.
>
> Yep. Sounds good to me.
>
>>
>>> The above approach as multiple advantages:
>>>
>>>  Compact: Since we use the (existing) bitfield, the storage cost is
>>> free (or minimal if we need to adds an extra byte of bitfield).
>>> Accessing the data is also very cheap:
>>>
>>>  Compoundable: We'll often needs to combine multiple markers to reports
>>> changesets between two revisions (eg: we do not have the intermediate
>>> revisions locally). the bit field approach makes it trivial to compound
>>> the information. We can display display the same final information when
>>> the same result if obtained from different path (eg: from two markers
>>> [content change; message change] or from one markers [content change |
>>> message change]).
>>>  This part is important because simply using operation name makes it
>>> quite hard to combine the information.
>>
>> Yes, if there were multiple operations we'd have to union them just as operation='modified' or something. Not ideal, but should be an outlier case.
>>
>>>  UI Abstraction: since we record the "effect" information, we abstract
>>> the command names. This makes use more agile about the actual UI. User
>>> can use their own "hg myownrewritetool" command and still record
>>> information useful for the other users.
>>
>> I think recording the actual command the user ran is important. The goal of showing this in the UI is to let the user know what past action caused this commit to become a new commit, so if they run 'hg flabbernate' it's much more useful to show them 'fblabbernated to be X' than it is to show them 'amended to be X'. So potentially, even if we have the bitfield data, it could still be important to record the actual command that caused this obsmarker to be created (ex: "amended to be X by hg flabbernate")
>
> I 100% agree here. The command verbs should map obviously onto the verbs that are saved in the obsmarkers.
Should this include aliases too? My initial gut reaction is 'yes' since
that would be what the user actually types and can help debug easier.

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

signature.asc (815 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Augie Fackler-2

On May 10, 2017, at 13:59, Sean Farley <[hidden email]> wrote:

Should this include aliases too? My initial gut reaction is 'yes' since
that would be what the user actually types and can help debug easier.

Maybe. Typically (not at G and F, but otherwise) users will have a vague sense of what their alias is configured to do.

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Sean Farley-3
Augie Fackler <[hidden email]> writes:

>> On May 10, 2017, at 13:59, Sean Farley <[hidden email]> wrote:
>>
>> Should this include aliases too? My initial gut reaction is 'yes' since
>> that would be what the user actually types and can help debug easier.
>
> Maybe. Typically (not at G and F, but otherwise) users will have a vague sense of what their alias is configured to do.

My thought is that users (myself included) have aliases for flags that
change behavior to the command, e.g.

amend_with_grandparent = amend -r .^^::

Seeing "amend_with_grandparent" would vastly help convey what I did as a
user. Though, if this is too complicated, I'm totally ok with ditching
it.

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

signature.asc (815 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Pierre-Yves David-2
In reply to this post by Durham Goode
On 05/10/2017 05:45 PM, Durham Goode wrote:

> On 5/10/17 3:40 AM, Pierre-Yves David wrote:
>> On 05/10/2017 01:34 AM, Durham Goode wrote:
>>> # HG changeset patch
>>> # User Durham Goode <[hidden email]>
>>> # Date 1494372571 25200
>>> #      Tue May 09 16:29:31 2017 -0700
>>> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>>> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>>> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>>
>> TL;DR; Storing more information is useful, but the pre-existing plans
>> aims at storing slightly different data in a different way. We should
>> stick to it.
>>
>> The idea is to use the obsmarker bitfields to store the data and record
>> a pre-defined set of "effects" in each markers. (eg: "content change,
>> message change, parent change")
>>
>> For examples:
>>
>> 1) a `hg amend` that update the diff will create a markers recording the
>> "content changes".
>>
>> 2) a `hg amend -e` that only update he commit message will record the
>> "message change".
>>
>> 3) a `hg rebase` will record the "parent change".
>>
>> 4) a `hg amend` that update the message, the content and user will
>> record these three things (content, message and meta changes).
>>
>> These data can then be used to have nice template as shown by Durham
>> (eg: is X is a successors of Y and the markers as some "content change"
>> bit, we can display "amended as Y"; if their are some parent change, we
>> can display "rebased as Y", if both are present "amended and rebased as
>> Y").
>>
>
> While having the above data seems nice, I don't know if it justifies not
> going with the current simple approach today. Otherwise we have to wait
> for this large obsstore refactor, which seems like a rather big
> dependency to block an important UX feature we could deliver today.

There seems to be a major misunderstanding here.

Obsmarkers -already- has a bitfield (for many years) so are -already-
able to use them to record actions. There are no delay or blocker here
everything is already in place for it. There are basically no reason to
not just do it.

> When the bit field is added in the future we can always change our
> templates and messaging to use that data as well.  And if it's good
> enough, we can drop the 'operation' metadata entirely, with little
> compatibility issue.
>
>> The above approach as multiple advantages:
>>
>>   Compact: Since we use the (existing) bitfield, the storage cost is
>> free (or minimal if we need to adds an extra byte of bitfield).
>> Accessing the data is also very cheap:
>>
>>   Compoundable: We'll often needs to combine multiple markers to reports
>> changesets between two revisions (eg: we do not have the intermediate
>> revisions locally). the bit field approach makes it trivial to compound
>> the information. We can display display the same final information when
>> the same result if obtained from different path (eg: from two markers
>> [content change; message change] or from one markers [content change |
>> message change]).
>>   This part is important because simply using operation name makes it
>> quite hard to combine the information.
>
> Yes, if there were multiple operations we'd have to union them just as
> operation='modified' or something. Not ideal, but should be an outlier
> case.

Having multiple markers between local changesets is the common case once
people start exchanging draft changesets. We can not dismiss this as an
outliers, behaving properly here is an actual request from the current
users.

>>   UI Abstraction: since we record the "effect" information, we abstract
>> the command names. This makes use more agile about the actual UI. User
>> can use their own "hg myownrewritetool" command and still record
>> information useful for the other users.
>
> I think recording the actual command the user ran is important. The goal
> of showing this in the UI is to let the user know what past action
> caused this commit to become a new commit, so if they run 'hg
> flabbernate' it's much more useful to show them 'fblabbernated to be X'
> than it is to show them 'amended to be X'. So potentially, even if we
> have the bitfield data, it could still be important to record the actual
> command that caused this obsmarker to be created (ex: "amended to be X
> by hg flabbernate")

Having more information is always useful, but this looks like something
to add as a second step.

The action-bit approach has clear advantages (no size concerns, clear
behavior with marker compositions), so this appears as a clear good
first step here.

In addition, if that first step turn out to not be enough and we want
more precise data we might want to look at leveraging the "hg journal"
local data for this.


I would recommend the following step forward:

1) add a simple "rewritten as" template,
2) record action-bit, use it in the template (and other related output),
3) gather data and look at the best way to issue more details.

By chance step (1) and (2) are on the list of UI improvement founded by
Unity (1) is about to be done (read: next week) and (2) is likely to be
scheduled in the next batch (read, this month).

If you want to work in this area, I recommend catching up with the
recent improvement in evolve and getting in touch with Boris Feld
(currently writing doing most of the lifting in this area).

Cheers,

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Matt Harbison-2
In reply to this post by Martin von Zweigbergk via Mercurial-devel
On Tue, 09 May 2017 19:55:57 -0400, Martin von Zweigbergk via  
Mercurial-devel <[hidden email]> wrote:

> On Tue, May 9, 2017 at 4:34 PM, Durham Goode <[hidden email]> wrote:
>> # HG changeset patch
>> # User Durham Goode <[hidden email]>
>> # Date 1494372571 25200
>> #      Tue May 09 16:29:31 2017 -0700
>> # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>> obsolete: add operation metadata to rebase/amend/histedit obsmarkers
>>
>> By recording what operation created the obsmarker, we can show very  
>> intuitive
>> messages to the user in various UIs. For instance, log output could have
>> messages like "Amended as XXX" to show why a commit is old and has an  
>> 'x' on it.
>
> Nice! I had previously assumed that that information was already in
> the obsmarker, but then I didn't find it in `hg debugobsolete`. I
> didn't realize it would be so easy to add. Seems like an obvious
> improvement. So obvious that I'm hesitating to queue it only because
> it seems like it should have been proposed before. Any idea why that
> hasn't happened?

It's not obsolete specific, so maybe not relevant, but operation metadata  
made me recall this thread:

https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-April/068692.html

>>
>>      @  ac28e3  durham
>>     /   First commit
>>    |
>>    | o  d4afe7 durham
>>    | |  Second commit
>>    | |
>>    | x  8e9a5d (Amended as ac28e3)  durham
>>    |/   First commit
>>    |
>>
>> diff --git a/hgext/histedit.py b/hgext/histedit.py
>> --- a/hgext/histedit.py
>> +++ b/hgext/histedit.py
>> @@ -1631,7 +1631,7 @@ def safecleanupnode(ui, repo, name, node
>>                               key=repo.changelog.rev)
>>          markers = [getmarker(t) for t in sortednodes]
>>          if markers:
>> -            obsolete.createmarkers(repo, markers)
>> +            obsolete.createmarkers(repo, markers, operation='histedit')
>>      else:
>>          return cleanupnode(ui, repo, name, nodes)
>>
>> diff --git a/hgext/rebase.py b/hgext/rebase.py
>> --- a/hgext/rebase.py
>> +++ b/hgext/rebase.py
>> @@ -1341,7 +1341,7 @@ def clearrebased(ui, repo, state, skippe
>>                      succs = (repo[newrev],)
>>                  markers.append((repo[rev], succs))
>>          if markers:
>> -            obsolete.createmarkers(repo, markers)
>> +            obsolete.createmarkers(repo, markers, operation='rebase')
>>      else:
>>          rebased = [rev for rev in state if state[rev] > nullmerge]
>>          if rebased:
>> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
>> --- a/mercurial/cmdutil.py
>> +++ b/mercurial/cmdutil.py
>> @@ -2740,7 +2740,7 @@ def amend(ui, repo, commitfunc, old, ext
>>                      if node:
>>                          obs.append((ctx, ()))
>>
>> -                    obsolete.createmarkers(repo, obs)
>> +                    obsolete.createmarkers(repo, obs,  
>> operation='amend')
>>          if not createmarkers and newid != old.node():
>>              # Strip the intermediate commit (if there was one) and the  
>> amended
>>              # commit
>> diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
>> --- a/mercurial/obsolete.py
>> +++ b/mercurial/obsolete.py
>> @@ -1204,7 +1204,8 @@ def _computedivergentset(repo):
>>      return divergent
>>
>>
>> -def createmarkers(repo, relations, flag=0, date=None, metadata=None):
>> +def createmarkers(repo, relations, flag=0, date=None, metadata=None,
>> +                  operation=None):
>>      """Add obsolete markers between changesets in a repo
>>
>>      <relations> must be an iterable of (<old>, (<new>,  
>> ...)[,{metadata}])
>> @@ -1225,6 +1226,8 @@ def createmarkers(repo, relations, flag=
>>          metadata = {}
>>      if 'user' not in metadata:
>>          metadata['user'] = repo.ui.username()
>> +    if operation:
>> +        metadata['operation'] = operation
>>      tr = repo.transaction('add-obsolescence-marker')
>>      try:
>>          markerargs = []
>> diff --git a/tests/test-histedit-obsolete.t  
>> b/tests/test-histedit-obsolete.t
>> --- a/tests/test-histedit-obsolete.t
>> +++ b/tests/test-histedit-obsolete.t
>> @@ -50,10 +50,10 @@ Test that histedit learns about obsolesc
>>    o  0:cb9a9f314b8b a
>>
>>    $ hg debugobsolete
>> -  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf  
>> 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
>> -  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0  
>> {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'user': 'test'} (glob)
>> -  1b2d564fad96311b45362f17c2aa855150efb35f  
>> 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'user': 'test'} (glob)
>> -  114f4176969ef342759a8a57e6bccefc4234829b  
>> 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
>> +  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf  
>> 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'amend',  
>> 'user': 'test'} (glob)
>> +  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0  
>> {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'operation': 'amend',  
>> 'user': 'test'} (glob)
>> +  1b2d564fad96311b45362f17c2aa855150efb35f  
>> 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  114f4176969ef342759a8a57e6bccefc4234829b  
>> 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>>
>>  With some node gone missing during the edit.
>>
>> @@ -80,14 +80,14 @@ With some node gone missing during the e
>>    o  0:cb9a9f314b8b a
>>
>>    $ hg debugobsolete
>> -  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf  
>> 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
>> -  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0  
>> {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'user': 'test'} (glob)
>> -  1b2d564fad96311b45362f17c2aa855150efb35f  
>> 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'user': 'test'} (glob)
>> -  114f4176969ef342759a8a57e6bccefc4234829b  
>> 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'user': 'test'} (glob)
>> -  76f72745eac0643d16530e56e2f86e36e40631f1  
>> 2ca853e48edbd6453a0674dc0fe28a0974c51b9c 0 (*) {'user': 'test'} (glob)
>> -  2ca853e48edbd6453a0674dc0fe28a0974c51b9c  
>> aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'user': 'test'} (glob)
>> -  49d44ab2be1b67a79127568a67c9c99430633b48  
>> 273c1f3b86267ed3ec684bb13af1fa4d6ba56e02 0 (*) {'user': 'test'} (glob)
>> -  46abc7c4d8738e8563e577f7889e1b6db3da4199  
>> aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'user': 'test'} (glob)
>> +  e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf  
>> 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation': 'amend',  
>> 'user': 'test'} (glob)
>> +  3e30a45cf2f719e96ab3922dfe039cfd047956ce 0  
>> {e72d22b19f8ecf4150ab4f91d0973fd9955d3ddf} (*) {'operation': 'amend',  
>> 'user': 'test'} (glob)
>> +  1b2d564fad96311b45362f17c2aa855150efb35f  
>> 46abc7c4d8738e8563e577f7889e1b6db3da4199 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  114f4176969ef342759a8a57e6bccefc4234829b  
>> 49d44ab2be1b67a79127568a67c9c99430633b48 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  76f72745eac0643d16530e56e2f86e36e40631f1  
>> 2ca853e48edbd6453a0674dc0fe28a0974c51b9c 0 (*) {'operation': 'amend',  
>> 'user': 'test'} (glob)
>> +  2ca853e48edbd6453a0674dc0fe28a0974c51b9c  
>> aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'operation': 'amend',  
>> 'user': 'test'} (glob)
>> +  49d44ab2be1b67a79127568a67c9c99430633b48  
>> 273c1f3b86267ed3ec684bb13af1fa4d6ba56e02 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  46abc7c4d8738e8563e577f7889e1b6db3da4199  
>> aba7da93703075eec9fb1dbaf143ff2bc1c49d46 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>>    $ cd ..
>>
>>  Base setup for the rest of the testing
>> @@ -170,13 +170,13 @@ Base setup for the rest of the testing
>>    o  0:cb9a9f314b8b a
>>
>>    $ hg debugobsolete
>> -  96e494a2d553dd05902ba1cee1d94d4cb7b8faed 0  
>> {b346ab9a313db8537ecf96fca3ca3ca984ef3bd7} (*) {'user': 'test'} (glob)
>> -  b558abc46d09c30f57ac31e85a8a3d64d2e906e4 0  
>> {96e494a2d553dd05902ba1cee1d94d4cb7b8faed} (*) {'user': 'test'} (glob)
>> -  d2ae7f538514cd87c17547b0de4cea71fe1af9fb 0  
>> {cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b} (*) {'user': 'test'} (glob)
>> -  177f92b773850b59254aa5e923436f921b55483b  
>> b346ab9a313db8537ecf96fca3ca3ca984ef3bd7 0 (*) {'user': 'test'} (glob)
>> -  055a42cdd88768532f9cf79daa407fc8d138de9b  
>> 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'user': 'test'} (glob)
>> -  e860deea161a2f77de56603b340ebbb4536308ae  
>> 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'user': 'test'} (glob)
>> -  652413bf663ef2a641cab26574e46d5f5a64a55a  
>> cacdfd884a9321ec4e1de275ef3949fa953a1f83 0 (*) {'user': 'test'} (glob)
>> +  96e494a2d553dd05902ba1cee1d94d4cb7b8faed 0  
>> {b346ab9a313db8537ecf96fca3ca3ca984ef3bd7} (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  b558abc46d09c30f57ac31e85a8a3d64d2e906e4 0  
>> {96e494a2d553dd05902ba1cee1d94d4cb7b8faed} (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  d2ae7f538514cd87c17547b0de4cea71fe1af9fb 0  
>> {cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b} (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  177f92b773850b59254aa5e923436f921b55483b  
>> b346ab9a313db8537ecf96fca3ca3ca984ef3bd7 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  055a42cdd88768532f9cf79daa407fc8d138de9b  
>> 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  e860deea161a2f77de56603b340ebbb4536308ae  
>> 59d9f330561fd6c88b1a6b32f0e45034d88db784 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>> +  652413bf663ef2a641cab26574e46d5f5a64a55a  
>> cacdfd884a9321ec4e1de275ef3949fa953a1f83 0 (*) {'operation':  
>> 'histedit', 'user': 'test'} (glob)
>>
>>
>>  Ensure hidden revision does not prevent histedit
>> diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
>> --- a/tests/test-obsolete.t
>> +++ b/tests/test-obsolete.t
>> @@ -1247,15 +1247,15 @@ only a subset of those are displayed (be
>>    adding d
>>    $ hg ci --amend -m dd
>>    $ hg debugobsolete --index --rev "3+7"
>> -  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1  
>> d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'user': 'test'} (re)
>> -  3 4715cf767440ed891755448016c2b8cf70760c30  
>> 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'user': 'test'} (re)
>> +  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1  
>> d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'operation':  
>> 'amend', 'user': 'test'} (re)
>> +  3 4715cf767440ed891755448016c2b8cf70760c30  
>> 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'operation':  
>> 'amend', 'user': 'test'} (re)
>>    $ hg debugobsolete --index --rev "3+7" -Tjson
>>    [
>>     {
>>      "date": *, (glob)
>>      "flag": 0,
>>      "index": 1,
>> -    "metadata": {"user": "test"},
>> +    "metadata": {"operation": "amend", "user": "test"},
>>      "precnode": "6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1",
>>      "succnodes": ["d27fb9b066076fd921277a4b9e8b9cb48c95bc6a"]
>>     },
>> @@ -1263,7 +1263,7 @@ only a subset of those are displayed (be
>>      "date": *, (glob)
>>      "flag": 0,
>>      "index": 3,
>> -    "metadata": {"user": "test"},
>> +    "metadata": {"operation": "amend", "user": "test"},
>>      "precnode": "4715cf767440ed891755448016c2b8cf70760c30",
>>      "succnodes": ["7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d"]
>>     }
>> @@ -1271,14 +1271,14 @@ only a subset of those are displayed (be
>>
>>  Test the --delete option of debugobsolete command
>>    $ hg debugobsolete --index
>> -  0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b  
>> f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'user': 'test'} (re)
>> -  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1  
>> d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'user': 'test'} (re)
>> -  2 1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74  
>> 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'user': 'test'} (re)
>> -  3 4715cf767440ed891755448016c2b8cf70760c30  
>> 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'user': 'test'} (re)
>> +  0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b  
>> f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'operation':  
>> 'amend', 'user': 'test'} (re)
>> +  1 6fdef60fcbabbd3d50e9b9cbc2a240724b91a5e1  
>> d27fb9b066076fd921277a4b9e8b9cb48c95bc6a 0 \(.*\) {'operation':  
>> 'amend', 'user': 'test'} (re)
>> +  2 1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74  
>> 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'operation':  
>> 'amend', 'user': 'test'} (re)
>> +  3 4715cf767440ed891755448016c2b8cf70760c30  
>> 7ae79c5d60f049c7b0dd02f5f25b9d60aaf7b36d 0 \(.*\) {'operation':  
>> 'amend', 'user': 'test'} (re)
>>    $ hg debugobsolete --delete 1 --delete 3
>>    deleted 2 obsolescence markers
>>    $ hg debugobsolete
>> -  cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b  
>> f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'user': 'test'} (re)
>> -  1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74  
>> 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'user': 'test'} (re)
>> +  cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b  
>> f9bd49731b0b175e42992a3c8fa6c678b2bc11f1 0 \(.*\) {'operation':  
>> 'amend', 'user': 'test'} (re)
>> +  1ab51af8f9b41ef8c7f6f3312d4706d870b1fb74  
>> 29346082e4a9e27042b62d2da0e2de211c027621 0 \(.*\) {'operation':  
>> 'amend', 'user': 'test'} (re)
>>    $ cd ..
>>
>> diff --git a/tests/test-rebase-obsolete.t b/tests/test-rebase-obsolete.t
>> --- a/tests/test-rebase-obsolete.t
>> +++ b/tests/test-rebase-obsolete.t
>> @@ -100,9 +100,9 @@ simple rebase
>>    o  0:cd010b8cd998 A
>>
>>    $ hg debugobsolete
>> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1  
>> e4e5be0395b2cbd471ed22a26b1b6a1a0658a794 0 (*) {'user': 'test'} (glob)
>> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 2327fea05063f39961b14cb69435a9898dc9a245 0 (*) {'user': 'test'} (glob)
>> -  32af7686d403cf45b5d95f2d70cebea587ac806a  
>> 8eeb3c33ad33d452c89e5dcf611c347f978fb42b 0 (*) {'user': 'test'} (glob)
>> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1  
>> e4e5be0395b2cbd471ed22a26b1b6a1a0658a794 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 2327fea05063f39961b14cb69435a9898dc9a245 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  32af7686d403cf45b5d95f2d70cebea587ac806a  
>> 8eeb3c33ad33d452c89e5dcf611c347f978fb42b 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>>
>>
>>    $ cd ..
>> @@ -170,9 +170,9 @@ set.
>>    o  0:cd010b8cd998 A
>>
>>    $ hg debugobsolete
>> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0  
>> {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
>> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
>> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0  
>> {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
>> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0  
>> {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0  
>> {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>>
>>
>>  More complex case where part of the rebase set were already rebased
>> @@ -180,10 +180,10 @@ More complex case where part of the reba
>>    $ hg rebase --rev 'desc(D)' --dest 'desc(H)'
>>    rebasing 9:08483444fef9 "D"
>>    $ hg debugobsolete
>> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0  
>> {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
>> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
>> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0  
>> {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
>> -  08483444fef91d6224f6655ee586a65d263ad34c  
>> 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'user': 'test'} (glob)
>> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0  
>> {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0  
>> {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  08483444fef91d6224f6655ee586a65d263ad34c  
>> 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>>    $ hg log -G
>>    @  11:4596109a6a43 D
>>    |
>> @@ -208,12 +208,12 @@ More complex case where part of the reba
>>    note: not rebasing 9:08483444fef9 "D", already in destination as  
>> 11:4596109a6a43 "D"
>>    rebasing 10:5ae4c968c6ac "C"
>>    $ hg debugobsolete
>> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0  
>> {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'user': 'test'} (glob)
>> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'user': 'test'} (glob)
>> -  32af7686d403cf45b5d95f2d70cebea587ac806a 0  
>> {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'user': 'test'} (glob)
>> -  08483444fef91d6224f6655ee586a65d263ad34c  
>> 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'user': 'test'} (glob)
>> -  8877864f1edb05d0e07dc4ba77b67a80a7b86672  
>> 462a34d07e599b87ea08676a449373fe4e2e1347 0 (*) {'user': 'test'} (glob)
>> -  5ae4c968c6aca831df823664e706c9d4aa34473d  
>> 98f6af4ee9539e14da4465128f894c274900b6e5 0 (*) {'user': 'test'} (glob)
>> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 0  
>> {cd010b8cd998f3981a5a8115f94f8da4ab506089} (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 5ae4c968c6aca831df823664e706c9d4aa34473d 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  32af7686d403cf45b5d95f2d70cebea587ac806a 0  
>> {5fddd98957c8a54a4d436dfe1da9d87f21a1b97b} (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  08483444fef91d6224f6655ee586a65d263ad34c  
>> 4596109a6a4328c398bde3a4a3b6737cfade3003 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  8877864f1edb05d0e07dc4ba77b67a80a7b86672  
>> 462a34d07e599b87ea08676a449373fe4e2e1347 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  5ae4c968c6aca831df823664e706c9d4aa34473d  
>> 98f6af4ee9539e14da4465128f894c274900b6e5 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>>    $ hg log --rev 'divergent()'
>>    $ hg log -G
>>    o  13:98f6af4ee953 C
>> @@ -349,9 +349,9 @@ collapse rebase
>>    $ hg id --debug -r tip
>>    4dc2197e807bae9817f09905b50ab288be2dbbcf tip
>>    $ hg debugobsolete
>> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1  
>> 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
>> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
>> -  32af7686d403cf45b5d95f2d70cebea587ac806a  
>> 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'user': 'test'} (glob)
>> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1  
>> 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  32af7686d403cf45b5d95f2d70cebea587ac806a  
>> 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>>
>>    $ cd ..
>>
>> @@ -411,9 +411,9 @@ not be rebased.
>>    o  0:cd010b8cd998 A
>>
>>    $ hg debugobsolete
>> -  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> e273c5e7d2d29df783dce9f9eaa3ac4adc69c15d 0 (*) {'user': 'test'} (glob)
>> -  32af7686d403cf45b5d95f2d70cebea587ac806a  
>> cf44d2f5a9f4297a62be94cbdd3dff7c7dc54258 0 (*) {'user': 'test'} (glob)
>> -  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1  
>> 7c6027df6a99d93f461868e5433f63bde20b6dfb 0 (*) {'user': 'test'} (glob)
>> +  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b  
>> e273c5e7d2d29df783dce9f9eaa3ac4adc69c15d 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  32af7686d403cf45b5d95f2d70cebea587ac806a  
>> cf44d2f5a9f4297a62be94cbdd3dff7c7dc54258 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>> +  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1  
>> 7c6027df6a99d93f461868e5433f63bde20b6dfb 0 (*) {'operation': 'rebase',  
>> 'user': 'test'} (glob)
>>
>>  Test that rewriting leaving instability behind is allowed
>>  ---------------------------------------------------------------------
>> _______________________________________________
>> Mercurial-devel mailing list
>> [hidden email]
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Gregory Szorc
In reply to this post by Pierre-Yves David-2
On Wed, May 10, 2017 at 1:08 PM, Pierre-Yves David <[hidden email]> wrote:
On 05/10/2017 05:45 PM, Durham Goode wrote:
On 5/10/17 3:40 AM, Pierre-Yves David wrote:
On 05/10/2017 01:34 AM, Durham Goode wrote:
# HG changeset patch
# User Durham Goode <[hidden email]>
# Date 1494372571 25200
#      Tue May 09 16:29:31 2017 -0700
# Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
# Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
obsolete: add operation metadata to rebase/amend/histedit obsmarkers

TL;DR; Storing more information is useful, but the pre-existing plans
aims at storing slightly different data in a different way. We should
stick to it.

The idea is to use the obsmarker bitfields to store the data and record
a pre-defined set of "effects" in each markers. (eg: "content change,
message change, parent change")

For examples:

1) a `hg amend` that update the diff will create a markers recording the
"content changes".

2) a `hg amend -e` that only update he commit message will record the
"message change".

3) a `hg rebase` will record the "parent change".

4) a `hg amend` that update the message, the content and user will
record these three things (content, message and meta changes).

These data can then be used to have nice template as shown by Durham
(eg: is X is a successors of Y and the markers as some "content change"
bit, we can display "amended as Y"; if their are some parent change, we
can display "rebased as Y", if both are present "amended and rebased as
Y").


While having the above data seems nice, I don't know if it justifies not
going with the current simple approach today. Otherwise we have to wait
for this large obsstore refactor, which seems like a rather big
dependency to block an important UX feature we could deliver today.

There seems to be a major misunderstanding here.

Obsmarkers -already- has a bitfield (for many years) so are -already- able to use them to record actions. There are no delay or blocker here everything is already in place for it. There are basically no reason to not just do it.

This is true. And nobody is denying that using bit flags is more optimal.

However, since we're not sure what we're doing with this feature yet, defining strings in the open-ended metadata field and then optimizing common values as bit flags later (possibly before 4.3 release) seems like a reasonable approach.
 

When the bit field is added in the future we can always change our
templates and messaging to use that data as well.  And if it's good
enough, we can drop the 'operation' metadata entirely, with little
compatibility issue.

The above approach as multiple advantages:

  Compact: Since we use the (existing) bitfield, the storage cost is
free (or minimal if we need to adds an extra byte of bitfield).
Accessing the data is also very cheap:

  Compoundable: We'll often needs to combine multiple markers to reports
changesets between two revisions (eg: we do not have the intermediate
revisions locally). the bit field approach makes it trivial to compound
the information. We can display display the same final information when
the same result if obtained from different path (eg: from two markers
[content change; message change] or from one markers [content change |
message change]).
  This part is important because simply using operation name makes it
quite hard to combine the information.

Yes, if there were multiple operations we'd have to union them just as
operation='modified' or something. Not ideal, but should be an outlier
case.

Having multiple markers between local changesets is the common case once people start exchanging draft changesets. We can not dismiss this as an outliers, behaving properly here is an actual request from the current users.

I don't think this matters today. Perfect is the enemy of good. We can also hack around this other ways, such as having the presence of multiple markers obsoleting a specific changeset via different methods change the UI.
 

  UI Abstraction: since we record the "effect" information, we abstract
the command names. This makes use more agile about the actual UI. User
can use their own "hg myownrewritetool" command and still record
information useful for the other users.

I think recording the actual command the user ran is important. The goal
of showing this in the UI is to let the user know what past action
caused this commit to become a new commit, so if they run 'hg
flabbernate' it's much more useful to show them 'fblabbernated to be X'
than it is to show them 'amended to be X'. So potentially, even if we
have the bitfield data, it could still be important to record the actual
command that caused this obsmarker to be created (ex: "amended to be X
by hg flabbernate")

Having more information is always useful, but this looks like something to add as a second step.

The action-bit approach has clear advantages (no size concerns, clear behavior with marker compositions), so this appears as a clear good first step here.

In addition, if that first step turn out to not be enough and we want more precise data we might want to look at leveraging the "hg journal" local data for this.


I would recommend the following step forward:

1) add a simple "rewritten as" template,
2) record action-bit, use it in the template (and other related output),
3) gather data and look at the best way to issue more details.

Since we're not sure what we're going to do yet, wasting limited bit flags when we have an open-ended metadata field is premature optimization. I support the approach in this patch. I also support converting things to bit flags before 4.3 if we establish confidence that the feature is working how we'd like.
 

By chance step (1) and (2) are on the list of UI improvement founded by Unity (1) is about to be done (read: next week) and (2) is likely to be scheduled in the next batch (read, this month).

If you want to work in this area, I recommend catching up with the recent improvement in evolve and getting in touch with Boris Feld (currently writing doing most of the lifting in this area).

Cheers,

--
Pierre-Yves David

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Augie Fackler-2

> On May 13, 2017, at 17:16, Gregory Szorc <[hidden email]> wrote:
>
>> I would recommend the following step forward:
>>
>> 1) add a simple "rewritten as" template,
>> 2) record action-bit, use it in the template (and other related output),
>> 3) gather data and look at the best way to issue more details.
>>
> Since we're not sure what we're going to do yet, wasting limited bit flags when we have an open-ended metadata field is premature optimization. I support the approach in this patch. I also support converting things to bit flags before 4.3 if we establish confidence that the feature is working how we'd like.

This sounds like a great approach to me - I share your hesitance around spending the limited bits in the flag field prematurely.
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Pierre-Yves David-2
In reply to this post by Gregory Szorc
TL;DR; There seems to be significant confusion remaining around the goal
and constraint of what we aims to do here. The email discussion is
moving slowly, I think we should switch to a more synchronous medium.

On 05/13/2017 11:16 PM, Gregory Szorc wrote:

> On Wed, May 10, 2017 at 1:08 PM, Pierre-Yves David
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     On 05/10/2017 05:45 PM, Durham Goode wrote:
>
>         On 5/10/17 3:40 AM, Pierre-Yves David wrote:
>
>             On 05/10/2017 01:34 AM, Durham Goode wrote:
>
>                 # HG changeset patch
>                 # User Durham Goode <[hidden email] <mailto:[hidden email]>>
>                 # Date 1494372571 25200
>                 #      Tue May 09 16:29:31 2017 -0700
>                 # Node ID 22051b0924bcbc5cde6d25d700dcce6afcaafd98
>                 # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
>                 obsolete: add operation metadata to
>                 rebase/amend/histedit obsmarkers
>
>
>             TL;DR; Storing more information is useful, but the
>             pre-existing plans
>             aims at storing slightly different data in a different way.
>             We should
>             stick to it.
>
>             The idea is to use the obsmarker bitfields to store the data
>             and record
>             a pre-defined set of "effects" in each markers. (eg:
>             "content change,
>             message change, parent change")
>
>             For examples:
>
>             1) a `hg amend` that update the diff will create a markers
>             recording the
>             "content changes".
>
>             2) a `hg amend -e` that only update he commit message will
>             record the
>             "message change".
>
>             3) a `hg rebase` will record the "parent change".
>
>             4) a `hg amend` that update the message, the content and
>             user will
>             record these three things (content, message and meta changes).
>
>             These data can then be used to have nice template as shown
>             by Durham
>             (eg: is X is a successors of Y and the markers as some
>             "content change"
>             bit, we can display "amended as Y"; if their are some parent
>             change, we
>             can display "rebased as Y", if both are present "amended and
>             rebased as
>             Y").
>
>
>         While having the above data seems nice, I don't know if it
>         justifies not
>         going with the current simple approach today. Otherwise we have
>         to wait
>         for this large obsstore refactor, which seems like a rather big
>         dependency to block an important UX feature we could deliver today.
>
>
>     There seems to be a major misunderstanding here.
>
>     Obsmarkers -already- has a bitfield (for many years) so are
>     -already- able to use them to record actions. There are no delay or
>     blocker here everything is already in place for it. There are
>     basically no reason to not just do it.
>
>
> This is true. And nobody is denying that using bit flags is more optimal.
>
> However, since we're not sure what we're doing with this feature yet,
> defining strings in the open-ended metadata field and then optimizing
> common values as bit flags later (possibly before 4.3 release) seems
> like a reasonable approach.

Using bit is not just about optimizing size for common values, it is
about recording more usable value too. Command name cannot be combined
(something we know we need) and has trouble carrying information across
users using different interfaces (something already happening today).

The planned alternative (recording "effect" on operation) does not
suffer from these two issues and are better suited for providing good
information for team using evolution.

>         When the bit field is added in the future we can always change our
>         templates and messaging to use that data as well.  And if it's good
>         enough, we can drop the 'operation' metadata entirely, with little
>         compatibility issue.
>
>             The above approach as multiple advantages:
>
>               Compact: Since we use the (existing) bitfield, the storage
>             cost is
>             free (or minimal if we need to adds an extra byte of bitfield).
>             Accessing the data is also very cheap:
>
>               Compoundable: We'll often needs to combine multiple
>             markers to reports
>             changesets between two revisions (eg: we do not have the
>             intermediate
>             revisions locally). the bit field approach makes it trivial
>             to compound
>             the information. We can display display the same final
>             information when
>             the same result if obtained from different path (eg: from
>             two markers
>             [content change; message change] or from one markers
>             [content change |
>             message change]).
>               This part is important because simply using operation name
>             makes it
>             quite hard to combine the information.
>
>
>         Yes, if there were multiple operations we'd have to union them
>         just as
>         operation='modified' or something. Not ideal, but should be an
>         outlier
>         case.
>
>
>     Having multiple markers between local changesets is the common case
>     once people start exchanging draft changesets. We can not dismiss
>     this as an outliers, behaving properly here is an actual request
>     from the current users.
>
>
> I don't think this matters today. Perfect is the enemy of good. We can
> also hack around this other ways, such as having the presence of
> multiple markers obsoleting a specific changeset via different methods
> change the UI.

I'm a bit confused by this part of your reply, I'm not sure how to read
it. Can you try to rephrase it to clarify again?


We know from field data and users request that it common to have a
linear chain of markers between locally known changeset (chain involving
locally unknown node). And team using evolution do requests better
reporting in this case.

However, the part in your reply about "presence of multiple markers
obsoleting a specific changeset" makes me think you are actually talking
about something else.

>               UI Abstraction: since we record the "effect" information,
>             we abstract
>             the command names. This makes use more agile about the
>             actual UI. User
>             can use their own "hg myownrewritetool" command and still record
>             information useful for the other users.
>
>
>         I think recording the actual command the user ran is important.
>         The goal
>         of showing this in the UI is to let the user know what past action
>         caused this commit to become a new commit, so if they run 'hg
>         flabbernate' it's much more useful to show them 'fblabbernated
>         to be X'
>         than it is to show them 'amended to be X'. So potentially, even
>         if we
>         have the bitfield data, it could still be important to record
>         the actual
>         command that caused this obsmarker to be created (ex: "amended
>         to be X
>         by hg flabbernate")
>
>
>     Having more information is always useful, but this looks like
>     something to add as a second step.
>
>     The action-bit approach has clear advantages (no size concerns,
>     clear behavior with marker compositions), so this appears as a clear
>     good first step here.
>
>     In addition, if that first step turn out to not be enough and we
>     want more precise data we might want to look at leveraging the "hg
>     journal" local data for this.
>
>
>     I would recommend the following step forward:
>
>     1) add a simple "rewritten as" template,
>     2) record action-bit, use it in the template (and other related output),
>     3) gather data and look at the best way to issue more details.
>
>
> Since we're not sure what we're going to do yet, wasting limited bit
> flags when we have an open-ended metadata field is premature
> optimization. I support the approach in this patch. I also support
> converting things to bit flags before 4.3 if we establish confidence
> that the feature is working how we'd like.

We have to keep in mind that the total size of markers is an important
factor here. There are already useful information excluded from markers
for size reason (eg: parent information for non-prune). We have to keep
being careful here and weight what extra data is the most important.
Adding command name would increase markers size by tens of percent.
Especially since markers will live forever in the project once created.

If exhausting bit flag is a concern, we can easily extend this bit
field. For now, we could store this extension in the metadata mapping,
and we would store them as an extra byte in the next obsstore format
(that we'll need soon at least for hash agility anyway).
We could easily dedicate a whole byte to store the proposed action bit
(and store it the marker extra for now, that would help adjusting bit
value over time).

Cheers,

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Augie Fackler-2

> On May 18, 2017, at 04:46, Pierre-Yves David <[hidden email]> wrote:
>
>>>    I would recommend the following step forward:
>>>
>>>    1) add a simple "rewritten as" template,
>>>    2) record action-bit, use it in the template (and other related output),
>>>    3) gather data and look at the best way to issue more details.
>>>
>>
>> Since we're not sure what we're going to do yet, wasting limited bit
>> flags when we have an open-ended metadata field is premature
>> optimization. I support the approach in this patch. I also support
>> converting things to bit flags before 4.3 if we establish confidence
>> that the feature is working how we'd like.
>
> We have to keep in mind that the total size of markers is an important factor here. There are already useful information excluded from markers for size reason (eg: parent information for non-prune). We have to keep being careful here and weight what extra data is the most important. Adding command name would increase markers size by tens of percent. Especially since markers will live forever in the project once created.

I understand that, but I think storing the command name is worthwhile as an experiment. I'd like us to be better about letting the perfect be the enemy of the good. I think we should go ahead and land this patch as-is, and if it turns out to be massively unwise we can back it out before 4.3.

Does anyone (other than Pierre-Yves, who has made his position very clear) object (strongly or weakly) to moving forward with this patch as stated?

Thanks!
Augie

> If exhausting bit flag is a concern, we can easily extend this bit field. For now, we could store this extension in the metadata mapping, and we would store them as an extra byte in the next obsstore format (that we'll need soon at least for hash agility anyway).
> We could easily dedicate a whole byte to store the proposed action bit (and store it the marker extra for now, that would help adjusting bit value over time).
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
12