{"thread":{"id":"7977","subject":"[RFC PATCH] Rename \"bury\" back to \"sink\".","startedAt":"2007-05-04T22:53:03Z","lastAt":"2007-05-13T19:06:05Z","messageCount":8,"participants":["Yann Dirson","Jakub Narebski","Karl Hasselström","Chris Shoemaker","David Kågedal"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"41101","messageId":"20070504224639.26133.6157.stgit@gandelf.nowhere.earth","threadId":"7977","inReplyTo":null,"subject":"[RFC PATCH] Rename \"bury\" back to \"sink\".","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-04T22:53:03Z","receivedAt":"2007-05-04T22:53:03Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"\nSigned-off-by: Yann Dirson <ydirson@altern.org>\n---\n\nWell, it looks like the voices we heard on this naming issue were\nquite equally cast towards each of the 2 name.\n\nLet my vote be to get back to \"sink\", so the user can easily pair the\ncommand with \"float\".  I expect that any previously-silent majoity\nprefering \"bury\" will talk now, before Catalin decides if he wants\nthis patch in the next release :)\n\nOh, this patch reminds me we still have to activate rename\ndetection...\n\n Documentation/stg-bury.txt    |   49 -------------------------------\n Documentation/stg-sink.txt    |   49 +++++++++++++++++++++++++++++++\n Documentation/stg.txt         |    4 +--\n contrib/stgit-completion.bash |    4 +--\n stgit/commands/bury.py        |   65 -----------------------------------------\n stgit/commands/sink.py        |   65 +++++++++++++++++++++++++++++++++++++++++\n stgit/main.py                 |    4 +--\n 7 files changed, 120 insertions(+), 120 deletions(-)\n\ndiff --git a/Documentation/stg-bury.txt b/Documentation/stg-bury.txt\ndeleted file mode 100644\nindex 22ab548..0000000\n--- a/Documentation/stg-bury.txt\n+++ /dev/null\n@@ -1,49 +0,0 @@\n-stg-bury(1)\n-===========\n-Yann Dirson <ydirson@altern.org>\n-v0.13, April 2007\n-\n-NAME\n-----\n-stg-bury - stgdesc:bury[]\n-\n-SYNOPSIS\n---------\n-[verse]\n-'stg' bury [--to=<target>] [--nopush] [<patches>]\n-\n-DESCRIPTION\n------------\n-\n-This is the opposite operation of stglink:float[]: move the specified\n-patches down the stack.  It is for example useful to group stable\n-patches near the bottom of the stack, where they are less likely to be\n-impacted by the push of another patch, and from where they can be more\n-easily committed or pushed.\n-\n-If no patch is specified on command-line, the current patch is buried.\n-By default patches are buried at the bottom of the stack, but the\n-'--to' option allows to bury under any applied patch.\n-\n-Buring internally involves popping all patches (or all patches\n-including <target patch>), then pushing the patches to bury, and then\n-(unless '--nopush' is also given) pushing back into place the\n-formerly-applied patches.\n-\n-\n-OPTIONS\n--------\n-\n---to=<TARGET>::\n--t <TARGET>::\n-\tSpecify a target patch to bury the patches below, instead of\n-\tburing at the bottom of the stack.\n-\n---nopush::\n--n::\n-\tDo not push back on the stack the formerly-applied patches.\n-\tOnly the patches to bury are pushed.\n-\n-StGIT\n------\n-Part of the StGIT suite - see gitlink:stg[1].\ndiff --git a/Documentation/stg-sink.txt b/Documentation/stg-sink.txt\nnew file mode 100644\nindex 0000000..0f569be\n--- /dev/null\n+++ b/Documentation/stg-sink.txt\n@@ -0,0 +1,49 @@\n+stg-sink(1)\n+===========\n+Yann Dirson <ydirson@altern.org>\n+v0.13, April 2007\n+\n+NAME\n+----\n+stg-sink - stgdesc:sink[]\n+\n+SYNOPSIS\n+--------\n+[verse]\n+'stg' sink [--to=<target>] [--nopush] [<patches>]\n+\n+DESCRIPTION\n+-----------\n+\n+This is the opposite operation of stglink:float[]: move the specified\n+patches down the stack.  It is for example useful to group stable\n+patches near the bottom of the stack, where they are less likely to be\n+impacted by the push of another patch, and from where they can be more\n+easily committed or pushed.\n+\n+If no patch is specified on command-line, the current patch gets sunk.\n+By default patches are sunk to the bottom of the stack, but the\n+'--to' option allows to place them under any applied patch.\n+\n+Sinking internally involves popping all patches (or all patches\n+including <target patch>), then pushing the patches to sink, and then\n+(unless '--nopush' is also given) pushing back into place the\n+formerly-applied patches.\n+\n+\n+OPTIONS\n+-------\n+\n+--to=<TARGET>::\n+-t <TARGET>::\n+\tSpecify a target patch to place the patches below, instead of\n+\tsinking them to the bottom of the stack.\n+\n+--nopush::\n+-n::\n+\tDo not push back on the stack the formerly-applied patches.\n+\tOnly the patches to sink are pushed.\n+\n+StGIT\n+-----\n+Part of the StGIT suite - see gitlink:stg[1].\ndiff --git a/Documentation/stg.txt b/Documentation/stg.txt\nindex cf28b02..af57c37 100644\n--- a/Documentation/stg.txt\n+++ b/Documentation/stg.txt\n@@ -137,8 +137,8 @@ stglink:goto[]::\n \tstgdesc:goto[]\n stglink:float[]::\n \tstgdesc:float[]\n-stglink:bury[]::\n-\tstgdesc:bury[]\n+stglink:sink[]::\n+\tstgdesc:sink[]\n stglink:applied[]::\n \tstgdesc:applied[]\n stglink:unapplied[]::\ndiff --git a/contrib/stgit-completion.bash b/contrib/stgit-completion.bash\nindex 3c3bf92..760fc2f 100644\n--- a/contrib/stgit-completion.bash\n+++ b/contrib/stgit-completion.bash\n@@ -15,7 +15,6 @@ _stg_commands=\"\n     applied\n     assimilate\n     branch\n-    bury\n     delete\n     diff\n     clean\n@@ -46,6 +45,7 @@ _stg_commands=\"\n     rm\n     series\n     show\n+    sink\n     status\n     sync\n     top\n@@ -190,13 +190,13 @@ _stg ()\n         # repository commands\n         id)     _stg_patches $command _all_patches ;;\n         # stack commands\n-        bury)   _stg_patches $command _all_patches ;;\n         float)  _stg_patches $command _all_patches ;;\n         goto)   _stg_patches $command _all_other_patches ;;\n         hide)   _stg_patches $command _all_patches ;;\n         pop)    _stg_patches $command _applied_patches ;;\n         push)   _stg_patches $command _unapplied_patches ;;\n         series) _stg_patches $command _all_patches ;;\n+        sink)   _stg_patches $command _all_patches ;;\n         unhide) _stg_patches $command _all_patches ;;\n         # patch commands\n         delete) _stg_patches $command _all_patches ;;\ndiff --git a/stgit/commands/bury.py b/stgit/commands/bury.py\ndeleted file mode 100644\nindex b14f09e..0000000\n--- a/stgit/commands/bury.py\n+++ /dev/null\n@@ -1,65 +0,0 @@\n-\n-__copyright__ = \"\"\"\n-Copyright (C) 2007, Yann Dirson <ydirson@altern.org>\n-\n-This program is free software; you can redistribute it and/or modify\n-it under the terms of the GNU General Public License version 2 as\n-published by the Free Software Foundation.\n-\n-This program is distributed in the hope that it will be useful,\n-but WITHOUT ANY WARRANTY; without even the implied warranty of\n-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n-GNU General Public License for more details.\n-\n-You should have received a copy of the GNU General Public License\n-along with this program; if not, write to the Free Software\n-Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n-\"\"\"\n-\n-import sys, os\n-from optparse import OptionParser, make_option\n-\n-from stgit.commands.common import *\n-from stgit.utils import *\n-from stgit import stack, git\n-\n-\n-help = 'bury patches down the stack'\n-usage = \"\"\"%prog [-t <target patch>] [-n] [<patches>]\n-\n-Pop all patches (or all patches including <target patch>), then\n-push the specified <patches> (the current patch by default), and\n-then push back into place the formerly-applied patches (unless -n\n-is also given).\"\"\"\n-\n-options = [make_option('-n', '--nopush',\n-                       help = 'do not push the patches back after sinking',\n-                       action = 'store_true'),\n-           make_option('-t', '--to', metavar = 'TARGET',\n-                       help = 'bury patches below TARGET patch')]\n-\n-def func(parser, options, args):\n-    \"\"\"Bury patches\n-    \"\"\"\n-\n-    check_local_changes()\n-    check_conflicts()\n-    check_head_top_equal()\n-\n-    oldapplied = crt_series.get_applied()\n-    unapplied = crt_series.get_unapplied()\n-    all = unapplied + oldapplied\n-\n-    if len(args) > 0:\n-        patches = parse_patches(args, all)\n-    else:\n-        patches = [ crt_series.get_current() ]\n-\n-    crt_series.pop_patch(options.to or oldapplied[0])\n-    push_patches(patches)\n-\n-    if not options.nopush:\n-        newapplied = crt_series.get_applied()\n-        def not_reapplied_yet(p):\n-            return not p in newapplied\n-        push_patches(filter(not_reapplied_yet, oldapplied))\ndiff --git a/stgit/commands/sink.py b/stgit/commands/sink.py\nnew file mode 100644\nindex 0000000..85cc70f\n--- /dev/null\n+++ b/stgit/commands/sink.py\n@@ -0,0 +1,65 @@\n+\n+__copyright__ = \"\"\"\n+Copyright (C) 2007, Yann Dirson <ydirson@altern.org>\n+\n+This program is free software; you can redistribute it and/or modify\n+it under the terms of the GNU General Public License version 2 as\n+published by the Free Software Foundation.\n+\n+This program is distributed in the hope that it will be useful,\n+but WITHOUT ANY WARRANTY; without even the implied warranty of\n+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n+GNU General Public License for more details.\n+\n+You should have received a copy of the GNU General Public License\n+along with this program; if not, write to the Free Software\n+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n+\"\"\"\n+\n+import sys, os\n+from optparse import OptionParser, make_option\n+\n+from stgit.commands.common import *\n+from stgit.utils import *\n+from stgit import stack, git\n+\n+\n+help = 'send patches deeper down the stack'\n+usage = \"\"\"%prog [-t <target patch>] [-n] [<patches>]\n+\n+Pop all patches (or all patches including <target patch>), then\n+push the specified <patches> (the current patch by default), and\n+then push back into place the formerly-applied patches (unless -n\n+is also given).\"\"\"\n+\n+options = [make_option('-n', '--nopush',\n+                       help = 'do not push the patches back after sinking',\n+                       action = 'store_true'),\n+           make_option('-t', '--to', metavar = 'TARGET',\n+                       help = 'sink patches below TARGET patch')]\n+\n+def func(parser, options, args):\n+    \"\"\"Sink patches down the stack.\n+    \"\"\"\n+\n+    check_local_changes()\n+    check_conflicts()\n+    check_head_top_equal()\n+\n+    oldapplied = crt_series.get_applied()\n+    unapplied = crt_series.get_unapplied()\n+    all = unapplied + oldapplied\n+\n+    if len(args) > 0:\n+        patches = parse_patches(args, all)\n+    else:\n+        patches = [ crt_series.get_current() ]\n+\n+    crt_series.pop_patch(options.to or oldapplied[0])\n+    push_patches(patches)\n+\n+    if not options.nopush:\n+        newapplied = crt_series.get_applied()\n+        def not_reapplied_yet(p):\n+            return not p in newapplied\n+        push_patches(filter(not_reapplied_yet, oldapplied))\ndiff --git a/stgit/main.py b/stgit/main.py\nindex 9c319c6..1a1f534 100644\n--- a/stgit/main.py\n+++ b/stgit/main.py\n@@ -63,7 +63,6 @@ commands = Commands({\n     'applied':          'applied',\n     'assimilate':       'assimilate',\n     'branch':           'branch',\n-    'bury':             'bury',\n     'delete':           'delete',\n     'diff':             'diff',\n     'clean':            'clean',\n@@ -94,6 +93,7 @@ commands = Commands({\n     'rm':               'rm',\n     'series':           'series',\n     'show':             'show',\n+    'sink':             'sink',\n     'status':           'status',\n     'sync':             'sync',\n     'top':              'top',\n@@ -111,7 +111,6 @@ stackcommands = (\n     'applied',\n     'assimilate',\n     'branch',\n-    'bury',\n     'clean',\n     'commit',\n     'float',\n@@ -124,6 +123,7 @@ stackcommands = (\n     'push',\n     'rebase',\n     'series',\n+    'sink',\n     'top',\n     'unapplied',\n     'uncommit',\n"},{"id":"41103","messageId":"f1gf8i$p52$1@sea.gmane.org","threadId":"7977","inReplyTo":"20070504224639.26133.6157.stgit@gandelf.nowhere.earth","subject":"Re: [RFC PATCH] Rename \"bury\" back to \"sink\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-04T23:22:54Z","receivedAt":"2007-05-04T23:22:54Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Yann Dirson wrote:\n\n> Well, it looks like the voices we heard on this naming issue were\n> quite equally cast towards each of the 2 name.\n> \n> Let my vote be to get back to \"sink\", so the user can easily pair the\n> command with \"float\".  I expect that any previously-silent majoity\n> prefering \"bury\" will talk now, before Catalin decides if he wants\n> this patch in the next release :)\n\nI'm rather partial to \"bury\" rather than \"sink\", as \"bury\" has the\nnotation of going deeper (like \"float\" has notation of guing up, to\nthe surface), while \"sink\" does not need to. Additionally \"sink\" is\na noun as well as a verb.\n\n> Oh, this patch reminds me we still have to activate rename\n> detection...\n\nTrue.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"41142","messageId":"20070505131352.GB3379@diana.vm.bytemark.co.uk","threadId":"7977","inReplyTo":"20070504224639.26133.6157.stgit@gandelf.nowhere.earth","subject":"Re: [RFC PATCH] Rename \"bury\" back to \"sink\".","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-05T13:13:53Z","receivedAt":"2007-05-05T13:13:53Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-05 00:53:03 +0200, Yann Dirson wrote:\n\n> Well, it looks like the voices we heard on this naming issue were\n> quite equally cast towards each of the 2 name.\n>\n> Let my vote be to get back to \"sink\", so the user can easily pair\n> the command with \"float\". I expect that any previously-silent\n> majoity prefering \"bury\" will talk now, before Catalin decides if he\n> wants this patch in the next release :)\n\nWell, my vote is still for \"sink\"! If it is to be called \"stg bury\",\nI'd have to vote for changing \"stg float\" to \"stg unearth\". :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"41145","messageId":"20070505173547.GA3540@pe.Belkin","threadId":"7977","inReplyTo":"20070505131352.GB3379@diana.vm.bytemark.co.uk","subject":"Re: [RFC PATCH] Rename \"bury\" back to \"sink\".","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-05-05T17:35:47Z","receivedAt":"2007-05-05T17:35:47Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Sat, May 05, 2007 at 03:13:53PM +0200, Karl Hasselström wrote:\n> On 2007-05-05 00:53:03 +0200, Yann Dirson wrote:\n> \n> > Well, it looks like the voices we heard on this naming issue were\n> > quite equally cast towards each of the 2 name.\n> >\n> > Let my vote be to get back to \"sink\", so the user can easily pair\n> > the command with \"float\". I expect that any previously-silent\n> > majoity prefering \"bury\" will talk now, before Catalin decides if he\n> > wants this patch in the next release :)\n> \n> Well, my vote is still for \"sink\"! If it is to be called \"stg bury\",\n> I'd have to vote for changing \"stg float\" to \"stg unearth\". :-)\n\nJust my 2.5 cents:\n\nfloat/sink are clearly related, while I wouldn't associate float/bury\nat all.  Also, \"bury\" is sometimes euphemistic for \"kill\", so\nbury/resurrect is a clear pair.  Anyway, \"sink\" makes perfect sense to\nme.\n\n-chris\n"},{"id":"41158","messageId":"20070505201307.GE19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"7977","inReplyTo":"f1gf8i$p52$1@sea.gmane.org","subject":"Re: [RFC PATCH] Rename \"bury\" back to \"sink\".","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-05T20:13:07Z","receivedAt":"2007-05-05T20:13:07Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"The whole debate around burying, sinking and floating patches made me\nthink a bit more about this.  So we have:\n\nfloat:\t\tmove specified patches to top of stack\nbury/float:\tmove specified patches to bottom of stack or any place\n\t\tin the stack identified by a nearby patch\n\nAll in all, that all \"move specified patches to a specified place\".\nSo wouldn't it be possible to end the debate by merging those commands\ninto a single \"stg move\" command ?\n\nSide note about the \"stg move\" name: yes it could possible to mistake it\nfor \"move file\" (especially as we don't have \"stg mv\").  My current\nstate of mind would be to drop add/rm/cp from stgit, and move the \"stg\ncp\" logic to a new git-cp command.  This way, stgit would just be\nabout handling series of patches, with git being used for the\nworking-copy.  Any opinions on this ?\n\nNow to the new command.  We could have something like:\n\n stg move -t base <patches>\t<=> stg sink <patches>\n stg move -t <patch> <patches>\t<=> stg sink -t <patch> <patches>\n stg move -t current <patches>\t<=> stg float <patches>\n\nNote the introduction of a new \"curent\" stg_id for the tip of the\nstack.\n\nThe semantics of the arg to -t would be something like \"the limit\nbetween the patches that will end up below <patches> and those that\nwill end up above\".  I suppose \"-t current\" should be the default, so\nit may not even be necessary to expose \"current\" to the command-line.\n\nThe \"conceptual algorithm\" would be:\n 1. stg pop <patches>\n 2. stg push <patches>\n 3. stg goto \"where I was\"\n\n\"-s [<series>]\" would be allowed as an alternative to <patches>, so\n\"move\" would be a strict superset of \"float\".\n\nBy default, consistently with \"float\", the <patches> (and hence\neverything originally under the target point) will end up applied if\nthe target of the move was \"within $applied\" (ie. an applied patch or\n\"current\" - something we could call \"below the surface\", hi float and\nsink ;), and all patches that were applied (ie. those between the\ntarget and the former tip) will end up being reapplied, consistently\nwith \"sink\".\n\nIf the target point is in $unapplied, then the command will be\nequivalent to \"stg pop <patches>\" with those patches reordered at the\ntarget (ie. no need to really execute steps 2 and 3 above).  That's no\nrocket science, but a useful I have already missed, eg. when I just\nwant to move the patches away from my working set (nowadays we could\nhide them, but that may not be always adequate).\n\nA --dont-come-back flag of some sort will skip step 3 of the\nconceptual algorithm above.  When the target will be in $applied, it\nwill be the equivalent of \"sink --nopush\".  When the target is in\n$unapplied, we will \"goto <last of <patches>>\" after reorering the\nunapplied patches.  Never missed this one till now, but who knows,\nthis side-effect might come handy.\n\nOpinions ?\n-- \nYann.\n\nPS: this RFC is known as \"bury sink and float\" ;)\n"},{"id":"41199","messageId":"20070506104944.GB17498@diana.vm.bytemark.co.uk","threadId":"7977","inReplyTo":"20070505201307.GE19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [RFC PATCH] Rename \"bury\" back to \"sink\".","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T10:49:44Z","receivedAt":"2007-05-06T10:49:44Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-05 22:13:07 +0200, Yann Dirson wrote:\n\n> The whole debate around burying, sinking and floating patches made\n> me think a bit more about this. So we have:\n>\n> float:        move specified patches to top of stack\n> bury/float:   move specified patches to bottom of stack or any place\n>               in the stack identified by a nearby patch\n>\n> All in all, that all \"move specified patches to a specified place\".\n> So wouldn't it be possible to end the debate by merging those\n> commands into a single \"stg move\" command ?\n\nI like that idea.\n\n  stg move patch1 --bottom\n  stg move patch1 --top\n  stg move patch1 --before other-patch\n  stg move patch1 --after other-patch\n  stg move patch1 --position 17 # move to absolute pos. 17 (bottom is 0)\n  stg move patch1 --up 3        # move 3 steps up\n  stg move patch1 --down 2      # move 2 steps down\n\nOr something. It could also be made to work with patch ranges as well\nas single patches.\n\n> Side note about the \"stg move\" name: yes it could possible to\n> mistake it for \"move file\" (especially as we don't have \"stg mv\").\n> My current state of mind would be to drop add/rm/cp from stgit, and\n> move the \"stg cp\" logic to a new git-cp command. This way, stgit\n> would just be about handling series of patches, with git being used\n> for the working-copy. Any opinions on this ?\n\nI would be in favor; I like to think of stgit as extending rather than\nproviding a complete replacement for the plain git porcelain. But as I\nrecall, Catalin didn't share my view on this. Better let him answer\nthe question himself than rely on my memory, though. ;-)\n\n> Now to the new command. We could have something like:\n>\n>  stg move -t base <patches>     <=> stg sink <patches>\n>  stg move -t <patch> <patches>  <=> stg sink -t <patch> <patches>\n>  stg move -t current <patches>  <=> stg float <patches>\n>\n> Note the introduction of a new \"curent\" stg_id for the tip of the\n> stack.\n\nAh, I wrote my suggested syntax above before reading yours. I like\nmine better, though. :-)\n\n> \"-s [<series>]\" would be allowed as an alternative to <patches>, so\n> \"move\" would be a strict superset of \"float\".\n\nAnother useful option would be to have --interactive open up an editor\nwith the patch names in it; the user could rearrange the lines any way\nshe pleased, and when the editor exits, the patch series is rearranged\nto match.\n\n> If the target point is in $unapplied, then the command will be\n> equivalent to \"stg pop <patches>\" with those patches reordered at\n> the target (ie. no need to really execute steps 2 and 3 above).\n> That's no rocket science, but a useful I have already missed, eg.\n> when I just want to move the patches away from my working set\n> (nowadays we could hide them, but that may not be always adequate).\n\nSounds very good.\n\n> Opinions?\n\nLots, as you just saw. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"42035","messageId":"87zm48wpbs.fsf@morpheus.local","threadId":"7977","inReplyTo":"20070505201307.GE19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [RFC PATCH] Rename \"bury\" back to \"sink\".","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-05-13T18:28:23Z","receivedAt":"2007-05-13T18:28:23Z","isPatch":true,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Yann Dirson <ydirson@altern.org> writes:\n\n> Side note about the \"stg move\" name: yes it could possible to mistake it\n> for \"move file\" (especially as we don't have \"stg mv\").  My current\n> state of mind would be to drop add/rm/cp from stgit, and move the \"stg\n> cp\" logic to a new git-cp command.  This way, stgit would just be\n> about handling series of patches, with git being used for the\n> working-copy.  Any opinions on this ?\n\nFor this reason, and others, I think \"stg reorder\" would be better.\nEspecially if you implement Karl's suggestion of reordering all\npatches in an editor.\n\n-- \nDavid Kågedal\n"},{"id":"42044","messageId":"20070513190605.GA14657@diana.vm.bytemark.co.uk","threadId":"7977","inReplyTo":"87zm48wpbs.fsf@morpheus.local","subject":"Re: [RFC PATCH] Rename \"bury\" back to \"sink\".","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-13T19:06:05Z","receivedAt":"2007-05-13T19:06:05Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-13 11:28:23 -0700, David Kågedal wrote:\n\n> For this reason, and others, I think \"stg reorder\" would be better.\n> Especially if you implement Karl's suggestion of reordering all\n> patches in an editor.\n\nSounds very sane to me.\n\nAdditionally, in order to appeal to users who like living on the edge,\nwe should probably consider implementing \"stg shuffle\".\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"}]}