[PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Yann Dirson]

This is the rewrite in python of by stg-sink written in perl.

I changed the name to "bury" since it seems more descriptive of what
it does, despite being less of an opposite to "float" than "sink" was.

Signed-off-by: Yann Dirson <ydirson@altern.org>
---

 Documentation/stg-bury.txt    |   49 +++++++++++++++++++++++++++++++
 Documentation/stg.txt         |    2 +
 contrib/stg-sink              |   44 ----------------------------
 contrib/stgit-completion.bash |    1 +
 stgit/commands/bury.py        |   65 +++++++++++++++++++++++++++++++++++++++++
 stgit/main.py                 |    2 +
 6 files changed, 119 insertions(+), 44 deletions(-)

diff --git a/Documentation/stg-bury.txt b/Documentation/stg-bury.txt
new file mode 100644
index 0000000..22ab548
--- /dev/null
+++ b/Documentation/stg-bury.txt
@@ -0,0 +1,49 @@
+stg-bury(1)
+===========
+Yann Dirson <ydirson@altern.org>
+v0.13, April 2007
+
+NAME
+----
+stg-bury - stgdesc:bury[]
+
+SYNOPSIS
+--------
+[verse]
+'stg' bury [--to=<target>] [--nopush] [<patches>]
+
+DESCRIPTION
+-----------
+
+This is the opposite operation of stglink:float[]: move the specified
+patches down the stack.  It is for example useful to group stable
+patches near the bottom of the stack, where they are less likely to be
+impacted by the push of another patch, and from where they can be more
+easily committed or pushed.
+
+If no patch is specified on command-line, the current patch is buried.
+By default patches are buried at the bottom of the stack, but the
+'--to' option allows to bury under any applied patch.
+
+Buring internally involves popping all patches (or all patches
+including <target patch>), then pushing the patches to bury, and then
+(unless '--nopush' is also given) pushing back into place the
+formerly-applied patches.
+
+
+OPTIONS
+-------
+
+--to=<TARGET>::
+-t <TARGET>::
+	Specify a target patch to bury the patches below, instead of
+	buring at the bottom of the stack.
+
+--nopush::
+-n::
+	Do not push back on the stack the formerly-applied patches.
+	Only the patches to bury are pushed.
+
+StGIT
+-----
+Part of the StGIT suite - see gitlink:stg[1].
diff --git a/Documentation/stg.txt b/Documentation/stg.txt
index a91b600..cf28b02 100644
--- a/Documentation/stg.txt
+++ b/Documentation/stg.txt
@@ -137,6 +137,8 @@ stglink:goto[]::
 	stgdesc:goto[]
 stglink:float[]::
 	stgdesc:float[]
+stglink:bury[]::
+	stgdesc:bury[]
 stglink:applied[]::
 	stgdesc:applied[]
 stglink:unapplied[]::
diff --git a/contrib/stg-sink b/contrib/stg-sink
deleted file mode 100755
index cb6e25d..0000000
--- a/contrib/stg-sink
+++ /dev/null
@@ -1,44 +0,0 @@
-#!/usr/bin/perl
-use strict;
-use warnings;
-
-sub _run {
-  #print(' >> ', @_, "\n");# and 0;
-  system(@_);
-}
-
-my $dopush=1;
-my $pop='pop -a';
-while (@ARGV and $ARGV[0] =~ m/^-/) {
-  if ($ARGV[0] eq '-n') {
-    $dopush=0;
-    shift @ARGV;
-  }
-  if ($ARGV[0] eq '-t') {
-    shift @ARGV;
-    $pop = 'goto '.shift @ARGV;
-  }
-}
-
-# default: sink current patch
-if (@ARGV == 0) {
-  $ARGV[0] = `stg top`;
-}
-
-my @oldapplied=`stg applied`;
-chomp (@oldapplied);
-
-_run('stg '.$pop) &&
-  die "cannot pop all patches";
-_run('stg push ' . join (' ', @ARGV)) &&
-  die "error pushing patches";
-
-if ($dopush) {
-  my @newapplied=`stg applied`;
-  chomp (@newapplied);
-  my @remaining=grep { my $check=$_;
-		       not grep { $check eq $_ } @newapplied;
-		     } @oldapplied;
-  _run('stg push ' . join (' ', @remaining)) &&
-    die "error pushing remaining patches";
-}
diff --git a/contrib/stgit-completion.bash b/contrib/stgit-completion.bash
index 09614dc..b6e1306 100644
--- a/contrib/stgit-completion.bash
+++ b/contrib/stgit-completion.bash
@@ -15,6 +15,7 @@ _stg_commands="
     applied
     assimilate
     branch
+    bury
     delete
     diff
     clean
diff --git a/stgit/commands/bury.py b/stgit/commands/bury.py
new file mode 100644
index 0000000..b14f09e
--- /dev/null
+++ b/stgit/commands/bury.py
@@ -0,0 +1,65 @@
+
+__copyright__ = """
+Copyright (C) 2007, Yann Dirson <ydirson@altern.org>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 2 as
+published by the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+"""
+
+import sys, os
+from optparse import OptionParser, make_option
+
+from stgit.commands.common import *
+from stgit.utils import *
+from stgit import stack, git
+
+
+help = 'bury patches down the stack'
+usage = """%prog [-t <target patch>] [-n] [<patches>]
+
+Pop all patches (or all patches including <target patch>), then
+push the specified <patches> (the current patch by default), and
+then push back into place the formerly-applied patches (unless -n
+is also given)."""
+
+options = [make_option('-n', '--nopush',
+                       help = 'do not push the patches back after sinking',
+                       action = 'store_true'),
+           make_option('-t', '--to', metavar = 'TARGET',
+                       help = 'bury patches below TARGET patch')]
+
+def func(parser, options, args):
+    """Bury patches
+    """
+
+    check_local_changes()
+    check_conflicts()
+    check_head_top_equal()
+
+    oldapplied = crt_series.get_applied()
+    unapplied = crt_series.get_unapplied()
+    all = unapplied + oldapplied
+
+    if len(args) > 0:
+        patches = parse_patches(args, all)
+    else:
+        patches = [ crt_series.get_current() ]
+
+    crt_series.pop_patch(options.to or oldapplied[0])
+    push_patches(patches)
+
+    if not options.nopush:
+        newapplied = crt_series.get_applied()
+        def not_reapplied_yet(p):
+            return not p in newapplied
+        push_patches(filter(not_reapplied_yet, oldapplied))
diff --git a/stgit/main.py b/stgit/main.py
index 856b868..9c319c6 100644
--- a/stgit/main.py
+++ b/stgit/main.py
@@ -63,6 +63,7 @@ commands = Commands({
     'applied':          'applied',
     'assimilate':       'assimilate',
     'branch':           'branch',
+    'bury':             'bury',
     'delete':           'delete',
     'diff':             'diff',
     'clean':            'clean',
@@ -110,6 +111,7 @@ stackcommands = (
     'applied',
     'assimilate',
     'branch',
+    'bury',
     'clean',
     'commit',
     'float',

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Sam Vilain]

Yann Dirson wrote:
> This is the rewrite in python of by stg-sink written in perl.
>
> I changed the name to "bury" since it seems more descriptive of what
> it does, despite being less of an opposite to "float" than "sink" was.
>   

But 'bury' means to hide or even kill.

How about "raise" and "lower" ?

Sam.

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Catalin Marinas]

On 17/04/07, Sam Vilain <sam@vilain.net> wrote:
> Yann Dirson wrote:
> > This is the rewrite in python of by stg-sink written in perl.
> >
> > I changed the name to "bury" since it seems more descriptive of what
> > it does, despite being less of an opposite to "float" than "sink" was.
>
> But 'bury' means to hide or even kill.
>
> How about "raise" and "lower" ?

Or "immerse" ("immerge"?) as another opposite of "float" :-)

I don't have any opinion on this, it's up to Yann to argue.

-- 
Catalin

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Junio C Hamano]

"Catalin Marinas" <catalin.marinas@gmail.com> writes:

> On 17/04/07, Sam Vilain <sam@vilain.net> wrote:
>> Yann Dirson wrote:
>> > This is the rewrite in python of by stg-sink written in perl.
>> >
>> > I changed the name to "bury" since it seems more descriptive of what
>> > it does, despite being less of an opposite to "float" than "sink" was.
>>
>> But 'bury' means to hide or even kill.
>>
>> How about "raise" and "lower" ?
>
> Or "immerse" ("immerge"?) as another opposite of "float" :-)
>
> I don't have any opinion on this, it's up to Yann to argue.

As a user, to me, 'bury' feels perfect and I am not annoyed by
the connotation, perhaps maybe I am used to 'bury-buffer' in
Emacs.

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Sam Vilain]

Junio C Hamano wrote:
>>> But 'bury' means to hide or even kill.
>>>
>>> How about "raise" and "lower" ?
>>>       
>> Or "immerse" ("immerge"?) as another opposite of "float" :-)
>>
>> I don't have any opinion on this, it's up to Yann to argue.
>>     
> As a user, to me, 'bury' feels perfect and I am not annoyed by
> the connotation, perhaps maybe I am used to 'bury-buffer' in
> Emacs.
>   

Sure... and from my own perspective as a user, I didn't even realise
what float did until now, and was surprised that "bury" would mean that.
The metaphor is a stack, not a pool or a sandpit. I don't think those
terms really assist in understanding, however cute they are.

Sam.

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Julian Phillips]

On Wed, 18 Apr 2007, Sam Vilain wrote:

> Junio C Hamano wrote:
>>>> But 'bury' means to hide or even kill.
>>>>
>>>> How about "raise" and "lower" ?
>>>>
>>> Or "immerse" ("immerge"?) as another opposite of "float" :-)
>>>
>>> I don't have any opinion on this, it's up to Yann to argue.
>>>
>> As a user, to me, 'bury' feels perfect and I am not annoyed by
>> the connotation, perhaps maybe I am used to 'bury-buffer' in
>> Emacs.
>>
>
> Sure... and from my own perspective as a user, I didn't even realise
> what float did until now, and was surprised that "bury" would mean that.
> The metaphor is a stack, not a pool or a sandpit. I don't think those
> terms really assist in understanding, however cute they are.

I find that bury is more natural than float (thinking of a stack of 
documents on a desk ...).  But then I don't use stg ...


-- 
Julian

  ---
Do nothing unless you must, and when you must act -- hesitate.

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Sam Vilain]

Julian Phillips wrote:
>> Sure... and from my own perspective as a user, I didn't even realise
>> what float did until now, and was surprised that "bury" would mean that.
>> The metaphor is a stack, not a pool or a sandpit. I don't think those
>> terms really assist in understanding, however cute they are.
>>     
>
> I find that bury is more natural than float (thinking of a stack of 
> documents on a desk ...).  But then I don't use stg ...
>   

You demonstrate my point :) by apparently missing that "bury" and
"float" are supposed to be the *opposite* of each other.

Sam.

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Julian Phillips]

On Wed, 18 Apr 2007, Sam Vilain wrote:

> Julian Phillips wrote:
>>> Sure... and from my own perspective as a user, I didn't even realise
>>> what float did until now, and was surprised that "bury" would mean that.
>>> The metaphor is a stack, not a pool or a sandpit. I don't think those
>>> terms really assist in understanding, however cute they are.
>>>
>>
>> I find that bury is more natural than float (thinking of a stack of
>> documents on a desk ...).  But then I don't use stg ...
>>
>
> You demonstrate my point :) by apparently missing that "bury" and
> "float" are supposed to be the *opposite* of each other.

I didn't mean to give that impression.  I was aware that they were 
opposites, but was only commenting on my view of the intuitivness of each.

I can't really think of a single metaphor where float and bury are both 
appropriate though.

-- 
Julian

  ---
He's dead, Jim.
 		-- McCoy, "The Devil in the Dark", stardate 3196.1

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Robin Rosenberg]

onsdag 18 april 2007 12:33 skrev Julian Phillips:
> On Wed, 18 Apr 2007, Sam Vilain wrote:
> 
> > Julian Phillips wrote:
> >>> Sure... and from my own perspective as a user, I didn't even realise
> >>> what float did until now, and was surprised that "bury" would mean that.
> >>> The metaphor is a stack, not a pool or a sandpit. I don't think those
> >>> terms really assist in understanding, however cute they are.
> >>>
> >>
> >> I find that bury is more natural than float (thinking of a stack of
> >> documents on a desk ...).  But then I don't use stg ...
> >>
> >
> > You demonstrate my point :) by apparently missing that "bury" and
> > "float" are supposed to be the *opposite* of each other.
> 
> I didn't mean to give that impression.  I was aware that they were 
> opposites, but was only commenting on my view of the intuitivness of each.
> 
> I can't really think of a single metaphor where float and bury are both 
> appropriate though.

The stack is transparent, so the "float" comes from thinking of the stack as a 
column (glass pillar) of water with things in it. So I wanted to float patches. I
didn't think too much about the name, it just popped out. At least that is what
I *think* I was thinking at the time.

The logical opposide thing is to "sink" things you don't work to work on.  "bury" 
implies  you don't see things, which just isn't true.

I did consider raise, but then you can raise things only a little. Floating a patch
makes it move all the way to the top.

-- robin

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Yann Dirson]

On Wed, Apr 18, 2007 at 10:19:26PM +0200, Robin Rosenberg wrote:
> > I can't really think of a single metaphor where float and bury are both 
> > appropriate though.
> 
> The stack is transparent, so the "float" comes from thinking of the stack as a 
> column (glass pillar) of water with things in it. So I wanted to float patches. I
> didn't think too much about the name, it just popped out. At least that is what
> I *think* I was thinking at the time.
> 
> The logical opposide thing is to "sink" things you don't work to work on.  "bury" 
> implies  you don't see things, which just isn't true.

Indeed, I originally planned to name it "sink", as the prototype
script.  It is when starting to write the documentation, that I
started to feel like writing "sink: bury patches down the stack", and
felt there was something wrong.  Since I could not find a plausible
description involving "sink", I finally went for "stg bury", although
I was not very pleased with it.

But if the consensus is that "sink" or something else sounds better, I
have myself no objection to bury "bury" :)

Best regards,
-- 
Yann.

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Karl Hasselström]

On 2007-04-18 22:35:02 +0200, Yann Dirson wrote:

> But if the consensus is that "sink" or something else sounds better,
> I have myself no objection to bury "bury" :)

I think that "sink" is by far the best word for it, especially when
paired with "float". (The only problem is that "stg series" prints the
stack with the bottom on top and the top at the bottom, but that's old
weirdness. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Catalin Marinas]

On 19/04/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-04-18 22:35:02 +0200, Yann Dirson wrote:
>
> > But if the consensus is that "sink" or something else sounds better,
> > I have myself no objection to bury "bury" :)
>
> I think that "sink" is by far the best word for it, especially when
> paired with "float". (The only problem is that "stg series" prints the
> stack with the bottom on top and the top at the bottom, but that's old
> weirdness. :-)

That's coming from quilt, I didn't spend much time on designing the
user interface (this is something to be done post 1.0). However, on
the CPUs I work the stack grows downwards but the top/bottom naming is
the opposite of StGIT one.

-- 
Catalin

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Yann Dirson]

On Sat, Apr 21, 2007 at 09:37:49AM +0000, Catalin Marinas wrote:
> On 19/04/07, Karl Hasselström <kha@treskal.com> wrote:
> >On 2007-04-18 22:35:02 +0200, Yann Dirson wrote:
> >
> >> But if the consensus is that "sink" or something else sounds better,
> >> I have myself no objection to bury "bury" :)
> >
> >I think that "sink" is by far the best word for it, especially when
> >paired with "float". (The only problem is that "stg series" prints the
> >stack with the bottom on top and the top at the bottom, but that's old
> >weirdness. :-)
> 
> That's coming from quilt, I didn't spend much time on designing the
> user interface (this is something to be done post 1.0). However, on
> the CPUs I work the stack grows downwards but the top/bottom naming is
> the opposite of StGIT one.

Anyway, it's been customary to have computer display coordinates to
"grow" from top to bottom, with "0" being the 1st line :)

Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.

[Karl Hasselström]

On 2007-04-21 09:37:49 +0000, Catalin Marinas wrote:

> On 19/04/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > (The only problem is that "stg series" prints the stack with the
> > bottom on top and the top at the bottom, but that's old weirdness.
> > :-)
>
> That's coming from quilt, I didn't spend much time on designing the
> user interface (this is something to be done post 1.0). However, on
> the CPUs I work the stack grows downwards but the top/bottom naming
> is the opposite of StGIT one.

Yes, I guessed that might be the origin. Additionally, when printing
the stack on a terminal it's actually best to print the bottom first,
so that at least the topmost patches aren't scrolled off the screen. I
don't really see a problem with this conflicting with all the rest of
StGIT considering the stack to grow from the bottom and upward. It's
just a benign quirk.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle