On 2007-08-23 15:09:48 +0100, Catalin Marinas wrote:
> On 06/08/07, Karl Hasselström <kha@xxxxxxxxxxx> 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.
> > 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
