Feature request: "bzr recommit"

[Michael Ellerman]

On 5/29/06, Jan Hudec <bulb at ucw.cz> wrote:
> On Mon, May 29, 2006 at 10:04:56 +1000, Michael Ellerman wrote:
> > On 5/28/06, Matthew D. Fuller <fullermd at over-yonder.net> wrote:
> > >On Sat, May 27, 2006 at 05:39:36PM +0200 I heard the voice of
> > >Matthieu Moy, and lo! it spake thus:
> > >>
> > >> So, my 2-cents-idea-of-the-day is to add a "recommit" command in the
> > >> uncommit plugin, that would uncommit, and then commit again with the
> > >> same log message.
> > >
> > >That would dovetail well with ideas to make interrupted/etc commits
> > >leave a log message lying around somewhere to be picked up when it's
> > >tried again.
> >
> > I like that idea better, ie. just a flag to commit to use the previous
> > message, and a standard place to find the message. It'd be useful for
> > shelf as well.
>
> Yes, I would prefer that over new command (recommit) as well.
> I would even say that when running a commit message editor, always load
> that 'previous' message into the editor as a default. Just carefuly so
> there is a way to abort the commit by quiting the editor.

I agree. That allows you to edit the message as you hack, and then
have bzr automatically bring that up when you commit. You can then
remember what you've been hacking on and either commit with that
message, if it's good enough, or edit it some.

> > What about '.bzrmessage' or something, analagous to '.bzrignore' ??
>
> The question is, whether the file should really be hidden. It might be
> useful to see whether you have some message prepared.

Hmm. I think it should be hidden, I don't think it's good Unix form to
drop files in peoples' source trees that aren't hidden.

cheers