All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
@ 2007-04-10 18:27 Yann Dirson
  2007-04-17 20:42 ` Sam Vilain
  0 siblings, 1 reply; 14+ messages in thread
From: Yann Dirson @ 2007-04-10 18:27 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: git


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',

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-10 18:27 [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink Yann Dirson
@ 2007-04-17 20:42 ` Sam Vilain
  2007-04-18  0:02   ` Catalin Marinas
  0 siblings, 1 reply; 14+ messages in thread
From: Sam Vilain @ 2007-04-17 20:42 UTC (permalink / raw)
  To: Yann Dirson; +Cc: Catalin Marinas, git

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-17 20:42 ` Sam Vilain
@ 2007-04-18  0:02   ` Catalin Marinas
  2007-04-18  0:10     ` Junio C Hamano
  0 siblings, 1 reply; 14+ messages in thread
From: Catalin Marinas @ 2007-04-18  0:02 UTC (permalink / raw)
  To: Sam Vilain; +Cc: Yann Dirson, git

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-18  0:02   ` Catalin Marinas
@ 2007-04-18  0:10     ` Junio C Hamano
  2007-04-18  2:49       ` Sam Vilain
  0 siblings, 1 reply; 14+ messages in thread
From: Junio C Hamano @ 2007-04-18  0:10 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: Sam Vilain, Yann Dirson, git

"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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-18  0:10     ` Junio C Hamano
@ 2007-04-18  2:49       ` Sam Vilain
  2007-04-18  7:41         ` Julian Phillips
  0 siblings, 1 reply; 14+ messages in thread
From: Sam Vilain @ 2007-04-18  2:49 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Catalin Marinas, Yann Dirson, git

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-18  2:49       ` Sam Vilain
@ 2007-04-18  7:41         ` Julian Phillips
  2007-04-18  8:58           ` Sam Vilain
  0 siblings, 1 reply; 14+ messages in thread
From: Julian Phillips @ 2007-04-18  7:41 UTC (permalink / raw)
  To: Sam Vilain; +Cc: Junio C Hamano, Catalin Marinas, Yann Dirson, git

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-18  7:41         ` Julian Phillips
@ 2007-04-18  8:58           ` Sam Vilain
  2007-04-18 10:33             ` Julian Phillips
  0 siblings, 1 reply; 14+ messages in thread
From: Sam Vilain @ 2007-04-18  8:58 UTC (permalink / raw)
  To: Julian Phillips; +Cc: Junio C Hamano, Catalin Marinas, Yann Dirson, git

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-18  8:58           ` Sam Vilain
@ 2007-04-18 10:33             ` Julian Phillips
  2007-04-18 20:19               ` Robin Rosenberg
  0 siblings, 1 reply; 14+ messages in thread
From: Julian Phillips @ 2007-04-18 10:33 UTC (permalink / raw)
  To: Sam Vilain; +Cc: Junio C Hamano, Catalin Marinas, Yann Dirson, git

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-18 10:33             ` Julian Phillips
@ 2007-04-18 20:19               ` Robin Rosenberg
  2007-04-18 20:35                 ` Yann Dirson
  0 siblings, 1 reply; 14+ messages in thread
From: Robin Rosenberg @ 2007-04-18 20:19 UTC (permalink / raw)
  To: Julian Phillips
  Cc: Sam Vilain, Junio C Hamano, Catalin Marinas, Yann Dirson, git

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-18 20:19               ` Robin Rosenberg
@ 2007-04-18 20:35                 ` Yann Dirson
  2007-04-19  8:59                   ` Karl Hasselström
  0 siblings, 1 reply; 14+ messages in thread
From: Yann Dirson @ 2007-04-18 20:35 UTC (permalink / raw)
  To: Robin Rosenberg
  Cc: Julian Phillips, Sam Vilain, Junio C Hamano, Catalin Marinas, git

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-18 20:35                 ` Yann Dirson
@ 2007-04-19  8:59                   ` Karl Hasselström
  2007-04-21  9:37                     ` Catalin Marinas
  0 siblings, 1 reply; 14+ messages in thread
From: Karl Hasselström @ 2007-04-19  8:59 UTC (permalink / raw)
  To: Yann Dirson
  Cc: Robin Rosenberg, Julian Phillips, Sam Vilain, Junio C Hamano,
	Catalin Marinas, git

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-19  8:59                   ` Karl Hasselström
@ 2007-04-21  9:37                     ` Catalin Marinas
  2007-04-21 10:15                       ` Yann Dirson
  2007-04-21 11:00                       ` Karl Hasselström
  0 siblings, 2 replies; 14+ messages in thread
From: Catalin Marinas @ 2007-04-21  9:37 UTC (permalink / raw)
  To: Karl Hasselström
  Cc: Yann Dirson, Robin Rosenberg, Julian Phillips, Sam Vilain,
	Junio C Hamano, git

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-21  9:37                     ` Catalin Marinas
@ 2007-04-21 10:15                       ` Yann Dirson
  2007-04-21 11:00                       ` Karl Hasselström
  1 sibling, 0 replies; 14+ messages in thread
From: Yann Dirson @ 2007-04-21 10:15 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Karl Hasselström, Robin Rosenberg, Julian Phillips,
	Sam Vilain, Junio C Hamano, git

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 :)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink.
  2007-04-21  9:37                     ` Catalin Marinas
  2007-04-21 10:15                       ` Yann Dirson
@ 2007-04-21 11:00                       ` Karl Hasselström
  1 sibling, 0 replies; 14+ messages in thread
From: Karl Hasselström @ 2007-04-21 11:00 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Yann Dirson, Robin Rosenberg, Julian Phillips, Sam Vilain,
	Junio C Hamano, git

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2007-04-21 11:01 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-10 18:27 [PATCH] Add "stg bury" command, with the functionnality of contrib/stg-sink Yann Dirson
2007-04-17 20:42 ` Sam Vilain
2007-04-18  0:02   ` Catalin Marinas
2007-04-18  0:10     ` Junio C Hamano
2007-04-18  2:49       ` Sam Vilain
2007-04-18  7:41         ` Julian Phillips
2007-04-18  8:58           ` Sam Vilain
2007-04-18 10:33             ` Julian Phillips
2007-04-18 20:19               ` Robin Rosenberg
2007-04-18 20:35                 ` Yann Dirson
2007-04-19  8:59                   ` Karl Hasselström
2007-04-21  9:37                     ` Catalin Marinas
2007-04-21 10:15                       ` Yann Dirson
2007-04-21 11:00                       ` Karl Hasselström

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.