On Tue, Jul 13, 2010 at 9:22 PM, Tero Koskinen
<address@hidden> wrote:
I also dislike the new commit message format. While I can
jump down 14 lines, I think the "jump" is an usability issue
and the behaviour should be reverted back to previous version.
Many editors (emacs, vi, nano at least) support a +N option which will move the cursor to the Nth line upon opening a file. Setting EDITOR="emacsclient +14" for example will put the cursor right where it needs to be and avoid having to manually position it before typing. This might be better done as a lua hook in the next version.
Obviously this doesn't fix the various issues people are experiencing but it may help in the short term.
It doesn't really surprise me that we're now hearing opinions on the new changelog editor, I had the feeling that things were too silent when we were discussing this and there's no doubt that this feature is in some sense an experiment and has a good chance of annoying or surprising people.
For those who didn't follow the discussion during development there were two things this change was attempting to do, in order of priority:
1. Deal with the issue of "oops, I forgot to specify a --branch option for this commit and now I have to start over" which is now handled by being able to see and change the branch you're committing to while editing the commit message.
2. Unify the output from status, commit and log as much as possible (perhaps this has gone too far). Previously status would display various things about the current workspace that included the list of changed files, branch information etc. in a completely haphazard (i.e. not like log) way and commit wouldn't display anything. By displaying the revision as it will look after it has been committed you get a chance to "preview" your commit and fix things you're not happy with.
I agree that all of the instructions and various possible BIG HAIRY WARNINGS are pretty damn ugly and doing something with them would be good. Ethan's proposal to keep the headers and move all the instructions and such below where the message is to go seems reasonable. Conditionally displaying fewer headers in status and commit is also an option, not removing leading/trailing whitespace can be changed, etc.
Cheers,
Derek