Re: [GSoC Proposal/RFC] Rolling commit message writing

[Avery Pennarun <apenwarr@gmail.com>]

On Sun, Mar 28, 2010 at 3:32 PM, Daniel Thomas <drt24@srcf.ucam.org> wrote:
> Currently it is fairly easy to write good commit messages but the effort
> that this requires of developers can be reduced still further.
>
> This would be achieved by adding a built in system for working on a commit
> message during the stage of adding changes.
>
> Currently this can be done manually using "-F <file>, --file=<file>" in git
> commit but we can do better than that. Specifically changes to git add
> [--interactive | -i] to add an 'am' or similar command to allow adding a
> file and then prompting for a message about the changes to that file. Also
> changes to git add [--patch | -p] to add 'm' and 'c' options to git add
> --patch to allow the addition of a message for the current hunk ('m') and to
> do a commit (prompting for review) before returning to the hunk currently in
> focus ('c').

The extra prompting seems to me like it would slow down the process of
'git add -p' by making it take too many steps.  Normally when I create
a commit, I like to think of "which lines will I commit?" and "what is
the description of the whole commit?" as separate questions, whereas
this workflow would interweave the two and confuse me.

Do other people prefer it that way?

Secondly, I'm concerned that if you can't remember the description of
your entire commit by the time you commit it, then your commit is too
big.  The usual solution is to create multiple, smaller commits that
are easy to describe.  If at the end you find yourself with too many
commits, you can always join them together with git rebase.

You might also like 'git commit -v', which shows the actual diff to be
committed as part of your default commit message.  Then you can write
your message while looking at it, making it easy to describe exactly
what you changed.

Given these existing capabilities, is it still worth adding the
feature you propose?

Have fun,

Avery