Thread (1 message) 1 message, 1 author, 2016-10-27
  • (off-list ancestor, not in this archive)
  • Re: feature request · Junio C Hamano <hidden> · 2016-10-27

Re: feature request

From: Junio C Hamano <hidden>
Date: 2016-10-27 22:47:08

John Rood [off-list ref] writes:
On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller [off-list ref] wrote:
quoted
On Thu, Oct 27, 2016 at 2:55 PM, John Rood [off-list ref] wrote:
quoted
Users should be able to configure Git to not send them into a Vim editor.

When users pull commits, and a new commit needs to be created for a
merge, Git's current way of determining a commit message is to send
the user into a Vim window so that they can write a message. There are
2 reasons why this might not be the ideal way to prompt for a commit
message.

1. Many users are used to writing concise one-line commit messages and
would not expect to save a commit message in a multi-line file. Some
users will wonder why they are in a text editor or which file they are
editing. Others may not, in fact, realize at all that a text editor is
what they are in.
Look at the -m option of git commit,
[administrivia: do not top post]
Thanks, I think changing the default for windows is a good idea.

The -m indeed accomplishes one-line messages when you are voluntarily
doing a commit. However, the scenario I mentioned is "When users pull
commits, and a new commit needs to be created for the merge"  In this
situation, the user isn't issuing the "git commit" command, and so
he/she doesn't have the opportunity to use the -m flag.
There is --no-edit there.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help