Re: Some ideas for StGIT

From: Karl Hasselström <kha@treskal.com>
Date: Aug 23, 2007, 14:34 UTC
Message-ID: <20070823143411.GA16051@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0708230709o6ae16d5dvcfeba2f344f57fa5@mail.gmail.com>

On 2007-08-23 15:09:48 +0100, Catalin Marinas wrote:

Show 19 quoted lines

> On 06/08/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-08-06 08:42:05 -0400, Pavel Roskin wrote:
> >
> > > Purely from the code standpoint, yes, it should be a separate
> > > command. But it may be practical to have both in one command,
> > > since I commonly need to change the description after changing
> > > the code.
> >
> > Sure. I don't have any objection to making
> >
> >   stg refresh -e
> >
> > be equivalent to
> >
> >   stg refresh && stg edit-patch-message <topmost-patch>
>
> The only objection is the long command name - 'stg edit [<patch>]'
> would be just fine.

Oh, I chose a ridiculously long name on purpose, to make it unambiguous while at the same time not implying that I had a good name already thought out. :-)

> It would also be nice to do (with an additional option), the
> equivalent of export - edit - import in case one wants to also
> modify the diff.

Yes. This is probably one of the most asked-for (and least implemented) features of StGIT.

Show 7 quoted lines

> > What I'm objecting to is being forced to refresh when I just want
> > to edit the message. (And, to a lesser degree, having to manually
> > push and pop to make the patch topmost before I can edit its
> > message.)
>
> Not necessarily - 'stg refresh -e -p <patch>' does the pop/push for
> you and it even uses the fast-forwarding.

Hmm, that's better. But it shouldn't be a refresh subcommand!

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