Patchwork [RFC] commit: add --reuse-message for keeping the old commit message during amend

login
register
mail settings
Submitter Durham Goode
Date Feb. 8, 2013, 9:34 p.m.
Message ID <a761c31f54ca302d65b3.1360359298@dev350.prn1.facebook.com>
Download mbox | patch
Permalink /patch/840/
State Deferred, archived
Headers show

Comments

Durham Goode - Feb. 8, 2013, 9:34 p.m.
# HG changeset patch
# User Durham Goode <durham@fb.com>
# Date 1360352769 28800
# Node ID a761c31f54ca302d65b33199f6c9368890267eba
# Parent  e2b176cf28e374eb146c3e131871631ab9ace537
commit: add --reuse-message for keeping the old commit message during amend

When people do 'hg commit --amend', most of the time they don't want to change
the commit message.  This adds a flag to do that without prompting the user.

I imagine most people will use it in an alias such as:

  amend=commit --amend --reuse-message

Questions:
- Anyone have a better name?  'reuse-message' matches git which is why it was
chosen, but it seems a little long.
- Marmoute proposed -L as the shortcut, since -l is used to specify a file as
the message. Thoughts?
Augie Fackler - Feb. 8, 2013, 11:05 p.m.
On Feb 8, 2013, at 9:34 PM, Durham Goode <durham@fb.com> wrote:

> # HG changeset patch
> # User Durham Goode <durham@fb.com>
> # Date 1360352769 28800
> # Node ID a761c31f54ca302d65b33199f6c9368890267eba
> # Parent  e2b176cf28e374eb146c3e131871631ab9ace537
> commit: add --reuse-message for keeping the old commit message during amend
> 
> When people do 'hg commit --amend', most of the time they don't want to change
> the commit message.  This adds a flag to do that without prompting the user.
> 
> I imagine most people will use it in an alias such as:
> 
>  amend=commit --amend --reuse-message
> 
> Questions:
> - Anyone have a better name?  'reuse-message' matches git which is why it was
> chosen, but it seems a little long.

I don't have a better one.

> - Marmoute proposed -L as the shortcut, since -l is used to specify a file as
> the message. Thoughts?
> 
> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
> --- a/mercurial/cmdutil.py
> +++ b/mercurial/cmdutil.py
> @@ -1702,7 +1702,7 @@
>                 date = opts.get('date') or old.date()
>             editmsg = False
>             if not message:
> -                editmsg = True
> +                editmsg = not opts.get('reuse_message')
>                 message = old.description()


Huh. Tests?

> 
>             pureextra = extra.copy()
> diff --git a/mercurial/commands.py b/mercurial/commands.py
> --- a/mercurial/commands.py
> +++ b/mercurial/commands.py
> @@ -1241,6 +1241,8 @@
>     ('', 'close-branch', None,
>      _('mark a branch as closed, hiding it from the branch list')),
>     ('', 'amend', None, _('amend the parent of the working dir')),
> +    ('', 'reuse-message', None,
> +      _('used with amend to reuse the previous commit message')),
>     ] + walkopts + commitopts + commitopts2 + subrepoopts,
>     _('[OPTION]... [FILE]...'))
> def commit(ui, repo, *pats, **opts):
> diff --git a/tests/test-debugcomplete.t b/tests/test-debugcomplete.t
> --- a/tests/test-debugcomplete.t
> +++ b/tests/test-debugcomplete.t
> @@ -197,7 +197,7 @@
>   add: include, exclude, subrepos, dry-run
>   annotate: rev, follow, no-follow, text, user, file, date, number, changeset, line-number, ignore-all-space, ignore-space-change, ignore-blank-lines, include, exclude
>   clone: noupdate, updaterev, rev, branch, pull, uncompressed, ssh, remotecmd, insecure
> -  commit: addremove, close-branch, amend, include, exclude, message, logfile, date, user, subrepos
> +  commit: addremove, close-branch, amend, reuse-message, include, exclude, message, logfile, date, user, subrepos
>   diff: rev, change, text, git, nodates, show-function, reverse, ignore-all-space, ignore-space-change, ignore-blank-lines, unified, stat, include, exclude, subrepos
>   export: output, switch-parent, rev, text, git, nodates
>   forget: include, exclude
> diff --git a/tests/test-qrecord.t b/tests/test-qrecord.t
> --- a/tests/test-qrecord.t
> +++ b/tests/test-qrecord.t
> @@ -61,6 +61,7 @@
>       --close-branch        mark a branch as closed, hiding it from the branch
>                             list
>       --amend               amend the parent of the working dir
> +      --reuse-message       used with amend to reuse the previous commit message
>    -I --include PATTERN [+] include names matching the given patterns
>    -X --exclude PATTERN [+] exclude names matching the given patterns
>    -m --message TEXT        use text as commit message
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Mads Kiilerich - Feb. 9, 2013, 10:21 a.m.
On 02/09/2013 12:05 AM, Augie Fackler wrote:
> On Feb 8, 2013, at 9:34 PM, Durham Goode <durham@fb.com> wrote:
>
>> # HG changeset patch
>> # User Durham Goode <durham@fb.com>
>> # Date 1360352769 28800
>> # Node ID a761c31f54ca302d65b33199f6c9368890267eba
>> # Parent  e2b176cf28e374eb146c3e131871631ab9ace537
>> commit: add --reuse-message for keeping the old commit message during amend
>>
>> When people do 'hg commit --amend', most of the time they don't want to change
>> the commit message.  This adds a flag to do that without prompting the user.
>>
>> I imagine most people will use it in an alias such as:
>>
>>   amend=commit --amend --reuse-message
>>
>> Questions:
>> - Anyone have a better name?  'reuse-message' matches git which is why it was
>> chosen, but it seems a little long.
> I don't have a better one.

We usually don't use '-' in option names.

(--reuse-message might be long, but it is still shorter than --config 
ui.editor=true ... and more cross platform. The feature is still nice to 
have, but not something completely new.)

It would perhaps be better to name the option after what it does instead 
of what it doesn't do. Perhaps something like 'filesonly'.

This option seems to be the opposite of 'qref -e' ... but I guess it is 
too late to change the default for amend ...

/Mads
Idan Kamara - Feb. 9, 2013, 10:29 a.m.
On Sat, Feb 9, 2013 at 12:21 PM, Mads Kiilerich <mads@kiilerich.com> wrote:
>
> On 02/09/2013 12:05 AM, Augie Fackler wrote:
>>
>> On Feb 8, 2013, at 9:34 PM, Durham Goode <durham@fb.com> wrote:
>>
>>> # HG changeset patch
>>> # User Durham Goode <durham@fb.com>
>>> # Date 1360352769 28800
>>> # Node ID a761c31f54ca302d65b33199f6c9368890267eba
>>> # Parent  e2b176cf28e374eb146c3e131871631ab9ace537
>>> commit: add --reuse-message for keeping the old commit message during
>>> amend
>>>
>>> When people do 'hg commit --amend', most of the time they don't want to
>>> change
>>> the commit message.  This adds a flag to do that without prompting the
>>> user.
>>>
>>> I imagine most people will use it in an alias such as:
>>>
>>>   amend=commit --amend --reuse-message
>>>
>>> Questions:
>>> - Anyone have a better name?  'reuse-message' matches git which is why
>>> it was
>>> chosen, but it seems a little long.
>>
>> I don't have a better one.
>
>
> We usually don't use '-' in option names.
>
> (--reuse-message might be long, but it is still shorter than --config
> ui.editor=true ... and more cross platform. The feature is still nice to
> have, but not something completely new.)
>
> It would perhaps be better to name the option after what it does instead
> of what it doesn't do. Perhaps something like 'filesonly'.
>
> This option seems to be the opposite of 'qref -e' ... but I guess it is
> too late to change the default for amend ...

Choosing that default was a pretty conscious choice (albeit with
some preferring the opposite):

http://markmail.org/message/a4jrwzq2232w6tcz
Durham Goode - Feb. 9, 2013, 11:05 a.m.
>We usually don't use '-' in option names.
>

--close-branch is an option on commit already, so there's some precedence.

>
>It would perhaps be better to name the option after what it does instead
>of what it doesn't do. Perhaps something like 'filesonly'.

I think --reuse-message is more intuitive.  In some way it does describe
what the commit does: it reuses the message.  And the name more closely
aligns with the user's intent.

>
>This option seems to be the opposite of 'qref -e' ... but I guess it is
>too late to change the default for amend ...

This would be ideal, but alas...
Pierre-Yves David - Feb. 9, 2013, 3:37 p.m.
On Sat, Feb 09, 2013 at 11:21:39AM +0100, Mads Kiilerich wrote:
> On 02/09/2013 12:05 AM, Augie Fackler wrote:
> >On Feb 8, 2013, at 9:34 PM, Durham Goode <durham@fb.com> wrote:
> >
> >># HG changeset patch
> >># User Durham Goode <durham@fb.com>
> >># Date 1360352769 28800
> >># Node ID a761c31f54ca302d65b33199f6c9368890267eba
> >># Parent  e2b176cf28e374eb146c3e131871631ab9ace537
> >>commit: add --reuse-message for keeping the old commit message during amend
> >>
> >>When people do 'hg commit --amend', most of the time they don't want to change
> >>the commit message.  This adds a flag to do that without prompting the user.
> >>
> >>I imagine most people will use it in an alias such as:
> >>
> >>  amend=commit --amend --reuse-message
> >>
> >>Questions:
> >>- Anyone have a better name?  'reuse-message' matches git which is why it was
> >>chosen, but it seems a little long.
> >I don't have a better one.
> 
> We usually don't use '-' in option names.
> 
> (--reuse-message might be long, but it is still shorter than
> --config ui.editor=true ... and more cross platform. The feature is
> still nice to have, but not something completely new.)

The name is not nice, but using the same option that git seems a good idea.
Pierre-Yves David - Feb. 9, 2013, 3:43 p.m.
On Sat, Feb 09, 2013 at 04:37:49PM +0100, Pierre-Yves David wrote:
> On Sat, Feb 09, 2013 at 11:21:39AM +0100, Mads Kiilerich wrote:
> > On 02/09/2013 12:05 AM, Augie Fackler wrote:
> > >On Feb 8, 2013, at 9:34 PM, Durham Goode <durham@fb.com> wrote:
> > >
> > >># HG changeset patch
> > >># User Durham Goode <durham@fb.com>
> > >># Date 1360352769 28800
> > >># Node ID a761c31f54ca302d65b33199f6c9368890267eba
> > >># Parent  e2b176cf28e374eb146c3e131871631ab9ace537
> > >>commit: add --reuse-message for keeping the old commit message during amend
> > >>
> > >>When people do 'hg commit --amend', most of the time they don't want to change
> > >>the commit message.  This adds a flag to do that without prompting the user.
> > >>
> > >>I imagine most people will use it in an alias such as:
> > >>
> > >>  amend=commit --amend --reuse-message
> > >>
> > >>Questions:
> > >>- Anyone have a better name?  'reuse-message' matches git which is why it was
> > >>chosen, but it seems a little long.
> > >I don't have a better one.
> > 
> > We usually don't use '-' in option names.
> > 
> > (--reuse-message might be long, but it is still shorter than
> > --config ui.editor=true ... and more cross platform. The feature is
> > still nice to have, but not something completely new.)
> 
> The name is not nice, but using the same option that git seems a good idea.

Augies told me that git's "reuse-message" takes a commit<stuff> at reuse the
message of this commit. It has no default option and therefore behave different
than we do here.


We need another name.
Idan Kamara - Feb. 12, 2013, 2:33 p.m.
On Fri, Feb 8, 2013 at 11:34 PM, Durham Goode <durham@fb.com> wrote:
>
> # HG changeset patch
> # User Durham Goode <durham@fb.com>
> # Date 1360352769 28800
> # Node ID a761c31f54ca302d65b33199f6c9368890267eba
> # Parent  e2b176cf28e374eb146c3e131871631ab9ace537
> commit: add --reuse-message for keeping the old commit message during
> amend
>
> When people do 'hg commit --amend', most of the time they don't want to
> change
> the commit message.  This adds a flag to do that without prompting the
> user.
>
> I imagine most people will use it in an alias such as:
>
>   amend=commit --amend --reuse-message
>
> Questions:
> - Anyone have a better name?  'reuse-message' matches git which is why it
> was
> chosen, but it seems a little long.

What about something generic like --no-editor? It's not as explicit
but we already have --editor which forces an editor, so this will do
the opposite.

It also opens up the possibility of appearing in other commands with
similar semantics but without being directly related to amend.
Durham Goode - Feb. 12, 2013, 9:08 p.m.
>  What about something generic like --no-editor? It's not as explicit
>  but we already have --editor which forces an editor, so this will do
>  the opposite.
>  
>  It also opens up the possibility of appearing in other commands with
>  similar semantics but without being directly related to amend.

I think the name must imply some relationship with another commit, so it's
semi intuitive that it's related to --amend. I think a user would be more
likely to try --no-editor without --amend, and be confused when it failed.
Idan Kamara - Feb. 12, 2013, 9:16 p.m.
On Tue, Feb 12, 2013 at 11:08 PM, Durham Goode <durham@fb.com> wrote:
>>  What about something generic like --no-editor? It's not as explicit
>>  but we already have --editor which forces an editor, so this will do
>>  the opposite.
>>
>>  It also opens up the possibility of appearing in other commands with
>>  similar semantics but without being directly related to amend.
>
> I think the name must imply some relationship with another commit, so it's
> semi intuitive that it's related to --amend. I think a user would be more
> likely to try --no-editor without --amend, and be confused when it failed.

The help text should (regardless of the name) say that this option is only
relevant when used with --amend.
Augie Fackler - Feb. 12, 2013, 9:48 p.m.
On Feb 12, 2013, at 4:16 PM, Idan Kamara <idankk86@gmail.com> wrote:

> On Tue, Feb 12, 2013 at 11:08 PM, Durham Goode <durham@fb.com> wrote:
>>> What about something generic like --no-editor? It's not as explicit
>>> but we already have --editor which forces an editor, so this will do
>>> the opposite.
>>> 
>>> It also opens up the possibility of appearing in other commands with
>>> similar semantics but without being directly related to amend.
>> 
>> I think the name must imply some relationship with another commit, so it's
>> semi intuitive that it's related to --amend. I think a user would be more
>> likely to try --no-editor without --amend, and be confused when it failed.
> 
> The help text should (regardless of the name) say that this option is only
> relevant when used with --amend.

Strawman alternative: a --fast-amend option that doesn't pop up an editor, so you can pass only one flag (that is, --fast-amend would be like --amend --reuse-message).

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Matt Mackall - Feb. 13, 2013, 4:56 a.m.
On Tue, 2013-02-12 at 16:48 -0500, Augie Fackler wrote:
> On Feb 12, 2013, at 4:16 PM, Idan Kamara <idankk86@gmail.com> wrote:
> 
> > On Tue, Feb 12, 2013 at 11:08 PM, Durham Goode <durham@fb.com> wrote:
> >>> What about something generic like --no-editor? It's not as explicit
> >>> but we already have --editor which forces an editor, so this will do
> >>> the opposite.
> >>> 
> >>> It also opens up the possibility of appearing in other commands with
> >>> similar semantics but without being directly related to amend.
> >> 
> >> I think the name must imply some relationship with another commit, so it's
> >> semi intuitive that it's related to --amend. I think a user would be more
> >> likely to try --no-editor without --amend, and be confused when it failed.
> > 
> > The help text should (regardless of the name) say that this option is only
> > relevant when used with --amend.
> 
> Strawman alternative: a --fast-amend option that doesn't pop up an
> editor, so you can pass only one flag (that is, --fast-amend would be
> like --amend --reuse-message).

I'm now inclined to think that 'hg commit --amend' will eventually be
replaced by 'hg amend', which will have a different default. Then we'll
deprecate --amend on commit.

So I think we should leave this alone. But I don't think we've got quite
enough experience here to add the new amend command yet.
Durham Goode - Feb. 13, 2013, 7:42 p.m.
On 2/12/13 8:56 PM, "Matt Mackall" <mpm@selenic.com> wrote:
>
>I'm now inclined to think that 'hg commit --amend' will eventually be
>replaced by 'hg amend', which will have a different default. Then we'll
>deprecate --amend on commit.
>
>So I think we should leave this alone. But I don't think we've got quite
>enough experience here to add the new amend command yet.


If anyone feels strongly about getting the extra commit flag in, speak up.
 For Facebook's purposes we will just add an amend alias for our users
that does 'hg --config ui.editor=true commit --amend' while we wait for
the real 'hg amend'.

As for having amend experience, as I've started using evolve more I've
found I use an amend flows in three ways:

1. (most common) Amending the code in the current commit
2. Amending the code in a commit further down.
3. (least common) Amending the commit description.

So my ideal "hg amend" would do #1 by default, #2 with "hg amend --to
'tip~2'", and #3 with "hg amend -e".  #2 is the only crazy one, but I've
been using a script that does it in one step and it makes editing chains
of commits much much easier.
Pierre-Yves David - Feb. 14, 2013, 10:23 a.m.
On Wed, Feb 13, 2013 at 07:42:44PM +0000, Durham Goode wrote:
> On 2/12/13 8:56 PM, "Matt Mackall" <mpm@selenic.com> wrote:
> >
> >I'm now inclined to think that 'hg commit --amend' will eventually be
> >replaced by 'hg amend', which will have a different default. Then we'll
> >deprecate --amend on commit.
> >
> >So I think we should leave this alone. But I don't think we've got quite
> >enough experience here to add the new amend command yet.

In evolve, I'll probably drop the internal "hg amend" code in favor of using "hg commit
--amend" with an altered editor.

> 
> 
> If anyone feels strongly about getting the extra commit flag in, speak up.
>  For Facebook's purposes we will just add an amend alias for our users
> that does 'hg --config ui.editor=true commit --amend' while we wait for
> the real 'hg amend'.

Note that you have to fix --config in alias first :-)

> As for having amend experience, as I've started using evolve more I've
> found I use an amend flows in three ways:
> 
> 1. (most common) Amending the code in the current commit
> 2. Amending the code in a commit further down.
> 3. (least common) Amending the commit description.

My most common usage are #1 and #3. I usually the "." commit as a "staging area"
slowly adding content and writing the commit message at the end.

The #2 operation is multi step

a) rebase your change on target commit (as hg update with dirty wc does)
b) amend
c) hg evolve --all descendant

It's probably something that we'll want but that requires first class support for multi step operation. Otherwise user will get terribly confused.

> So my ideal "hg amend" would do #1 by default, #2 with "hg amend --to
> 'tip~2'", and #3 with "hg amend -e".  #2 is the only crazy one, but I've
> been using a script that does it in one step and it makes editing chains
> of commits much much easier.
Augie Fackler - Feb. 20, 2013, 1:35 a.m.
On Feb 14, 2013, at 5:23 AM, Pierre-Yves David <pierre-yves.david@logilab.fr> wrote:

> On Wed, Feb 13, 2013 at 07:42:44PM +0000, Durham Goode wrote:
>> On 2/12/13 8:56 PM, "Matt Mackall" <mpm@selenic.com> wrote:
>>> 
>>> I'm now inclined to think that 'hg commit --amend' will eventually be
>>> replaced by 'hg amend', which will have a different default. Then we'll
>>> deprecate --amend on commit.
>>> 
>>> So I think we should leave this alone. But I don't think we've got quite
>>> enough experience here to add the new amend command yet.
> 
> In evolve, I'll probably drop the internal "hg amend" code in favor of using "hg commit
> --amend" with an altered editor.

Hm. I think it's bad practice for extensions to alter the behavior of off the shelf commands with off the shelf flags - I've done that in the past and always regretted it.

> 
>> 
>> 
>> If anyone feels strongly about getting the extra commit flag in, speak up.
>> For Facebook's purposes we will just add an amend alias for our users
>> that does 'hg --config ui.editor=true commit --amend' while we wait for
>> the real 'hg amend'.
> 
> Note that you have to fix --config in alias first :-)
> 
>> As for having amend experience, as I've started using evolve more I've
>> found I use an amend flows in three ways:
>> 
>> 1. (most common) Amending the code in the current commit
>> 2. Amending the code in a commit further down.
>> 3. (least common) Amending the commit description.
> 
> My most common usage are #1 and #3. I usually the "." commit as a "staging area"
> slowly adding content and writing the commit message at the end.
> 
> The #2 operation is multi step
> 
> a) rebase your change on target commit (as hg update with dirty wc does)
> b) amend
> c) hg evolve --all descendant
> 
> It's probably something that we'll want but that requires first class support for multi step operation. Otherwise user will get terribly confused.
> 
>> So my ideal "hg amend" would do #1 by default, #2 with "hg amend --to
>> 'tip~2'", and #3 with "hg amend -e".  #2 is the only crazy one, but I've
>> been using a script that does it in one step and it makes editing chains
>> of commits much much easier.
> 
> -- 
> Pierre-Yves David
> 
> http://www.logilab.fr/
>
Matt Mackall - Feb. 20, 2013, 6:42 p.m.
On Tue, 2013-02-19 at 20:35 -0500, Augie Fackler wrote:
> On Feb 14, 2013, at 5:23 AM, Pierre-Yves David <pierre-yves.david@logilab.fr> wrote:
> 
> > On Wed, Feb 13, 2013 at 07:42:44PM +0000, Durham Goode wrote:
> >> On 2/12/13 8:56 PM, "Matt Mackall" <mpm@selenic.com> wrote:
> >>> 
> >>> I'm now inclined to think that 'hg commit --amend' will eventually be
> >>> replaced by 'hg amend', which will have a different default. Then we'll
> >>> deprecate --amend on commit.
> >>> 
> >>> So I think we should leave this alone. But I don't think we've got quite
> >>> enough experience here to add the new amend command yet.
> > 
> > In evolve, I'll probably drop the internal "hg amend" code in favor of using "hg commit
> > --amend" with an altered editor.
> 
> Hm. I think it's bad practice for extensions to alter the behavior of
> off the shelf commands with off the shelf flags - I've done that in
> the past and always regretted it.

I think you misread his proposal.

Patch

diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
--- a/mercurial/cmdutil.py
+++ b/mercurial/cmdutil.py
@@ -1702,7 +1702,7 @@ 
                 date = opts.get('date') or old.date()
             editmsg = False
             if not message:
-                editmsg = True
+                editmsg = not opts.get('reuse_message')
                 message = old.description()
 
             pureextra = extra.copy()
diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -1241,6 +1241,8 @@ 
     ('', 'close-branch', None,
      _('mark a branch as closed, hiding it from the branch list')),
     ('', 'amend', None, _('amend the parent of the working dir')),
+    ('', 'reuse-message', None,
+      _('used with amend to reuse the previous commit message')),
     ] + walkopts + commitopts + commitopts2 + subrepoopts,
     _('[OPTION]... [FILE]...'))
 def commit(ui, repo, *pats, **opts):
diff --git a/tests/test-debugcomplete.t b/tests/test-debugcomplete.t
--- a/tests/test-debugcomplete.t
+++ b/tests/test-debugcomplete.t
@@ -197,7 +197,7 @@ 
   add: include, exclude, subrepos, dry-run
   annotate: rev, follow, no-follow, text, user, file, date, number, changeset, line-number, ignore-all-space, ignore-space-change, ignore-blank-lines, include, exclude
   clone: noupdate, updaterev, rev, branch, pull, uncompressed, ssh, remotecmd, insecure
-  commit: addremove, close-branch, amend, include, exclude, message, logfile, date, user, subrepos
+  commit: addremove, close-branch, amend, reuse-message, include, exclude, message, logfile, date, user, subrepos
   diff: rev, change, text, git, nodates, show-function, reverse, ignore-all-space, ignore-space-change, ignore-blank-lines, unified, stat, include, exclude, subrepos
   export: output, switch-parent, rev, text, git, nodates
   forget: include, exclude
diff --git a/tests/test-qrecord.t b/tests/test-qrecord.t
--- a/tests/test-qrecord.t
+++ b/tests/test-qrecord.t
@@ -61,6 +61,7 @@ 
       --close-branch        mark a branch as closed, hiding it from the branch
                             list
       --amend               amend the parent of the working dir
+      --reuse-message       used with amend to reuse the previous commit message
    -I --include PATTERN [+] include names matching the given patterns
    -X --exclude PATTERN [+] exclude names matching the given patterns
    -m --message TEXT        use text as commit message