# feature request 14 messages from 2016-10-27 to 2016-10-28. Participants: John Rood, Stefan Beller, Junio C Hamano, David Lang, Johannes Schindelin, Philip Oakley. Thread: https://gitlist.dev/t/44384 ## John Rood, 2016-10-27 21:55 Subject: feature request Message-ID: URL: https://gitlist.dev/e/CALj-rGeoT_mpmuw8Put%3D6eRhzf-r2WUohu_Kd-wnpc%3DBvO5joA%40mail.gmail.com ``` 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. 2. Many users are not familiar with Vim, and do not understand how to modify, save, and exit. It is not very considerate to require a user to learn Vim in order to finish a commit that they are in the middle of. The existing behavior should be optional, and there should be two new options: 1. Use a simple inline prompt for a commit message (in the same way Git might prompt for a username). 2. Automatically assign names for commits in the form of "Merged x into y". ``` ## Stefan Beller, 2016-10-27 22:01 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/CAGZ79kZAfqxB699MOs6A6RL%3D%3DKu-qF7ABiW%3DeA%2BTSrqK%2B8e_sA%40mail.gmail.com In-Reply-To: ``` On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: > Users should be able to configure Git to not send them into a Vim editor. See https://git-scm.com/docs/git-var GIT_EDITOR Text editor for use by Git commands. The value is meant to be interpreted by the shell when it is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE, "C:\Program Files\Vim\gvim.exe" --nofork. The order of preference is the $GIT_EDITOR environment variable, then core.editor configuration, then $VISUAL, then $EDITOR, and then the default chosen at compile time, which is usually vi. So maybe git config --global core.editor "nano" helps in your case? ``` ## John Rood, 2016-10-27 22:05 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/CALj-rGeMHyN6Xhc0_KCChmWL4BDyF-ZJYdipbe1_yNvznrYPVA%40mail.gmail.com In-Reply-To: ``` Unfortunately, in my case I'm on windows (my company's choice, not mine). On Thu, Oct 27, 2016 at 5:01 PM, Stefan Beller wrote: > On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: >> Users should be able to configure Git to not send them into a Vim editor. > > See https://git-scm.com/docs/git-var > > GIT_EDITOR > > Text editor for use by Git commands. The value is meant to be interpreted > by the shell when it is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE, > "C:\Program Files\Vim\gvim.exe" --nofork. The order of preference is the > $GIT_EDITOR environment variable, then core.editor configuration, then > $VISUAL, then $EDITOR, and then the default chosen at compile time, > which is usually vi. > > > So maybe > > git config --global core.editor "nano" > > helps in your case? ``` ## John Rood, 2016-10-27 22:24 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/CALj-rGfsy%2BKA%3Ddsd%2BwobMiVOWHK1GU%3DdZRcQWtMoXwtBrMYPLg%40mail.gmail.com In-Reply-To: ``` I suppose I can do git config --global core.editor notepad However, this really only addresses my second concern. My first concern is that using a text editor at all seems like overkill in many scenarios. For that reason, I still think the other two options I mentioned would be beneficial. On Thu, Oct 27, 2016 at 5:05 PM, John Rood wrote: > Unfortunately, in my case I'm on windows (my company's choice, not mine). > > On Thu, Oct 27, 2016 at 5:01 PM, Stefan Beller wrote: >> On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: >>> Users should be able to configure Git to not send them into a Vim editor. >> >> See https://git-scm.com/docs/git-var >> >> GIT_EDITOR >> >> Text editor for use by Git commands. The value is meant to be interpreted >> by the shell when it is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE, >> "C:\Program Files\Vim\gvim.exe" --nofork. The order of preference is the >> $GIT_EDITOR environment variable, then core.editor configuration, then >> $VISUAL, then $EDITOR, and then the default chosen at compile time, >> which is usually vi. >> >> >> So maybe >> >> git config --global core.editor "nano" >> >> helps in your case? ``` ## Junio C Hamano, 2016-10-27 22:27 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/xmqq1sz15swv.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` John Rood writes: > I suppose I can do git config --global core.editor notepad > However, this really only addresses my second concern. > > My first concern is that using a text editor at all seems like > overkill in many scenarios. Nobody stops you from writing a "type whatever you want; I won't let you edit any mistakes as I am not even a text editor; just hit RETURN when you are done, as you can only write a single line" program and set it as your GIT_EDITOR. I do not know what would happen when you need "git commit --amend", though. ``` ## Stefan Beller, 2016-10-27 22:30 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/CAGZ79ka7BvaW2pkjeXe68yKHFq6JsH__x2cXoe6U4tRmZ0rY1A%40mail.gmail.com In-Reply-To: ``` On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: > 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, git commit -a -m "look a commit with no editor, and a precise one line message" I do not advocate this use though, as I think commit messages should be more wordy. > > 2. Many users are not familiar with Vim, and do not understand how to > modify, save, and exit. It is not very considerate to require a user > to learn Vim in order to finish a commit that they are in the middle > of. That is true, but vi is like the most available editor as a relict from ancient times; as you are on Windows, maybe notepad is the best on that platform. Maybe file a bug/issue at https://github.com/git-for-windows to change the default? > > The existing behavior should be optional, and there should be two new options: > > 1. Use a simple inline prompt for a commit message (in the same way > Git might prompt for a username). > > 2. Automatically assign names for commits in the form of "Merged x into y". ``` ## John Rood, 2016-10-27 22:44 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/CALj-rGfAyimf0nFFcDHVHUgj8PQaz6Cvoz_PQfqdhr%3DQJEpbRw%40mail.gmail.com In-Reply-To: ``` 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. On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller wrote: > On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: >> 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, > > git commit -a -m "look a commit with no editor, and a precise one line message" > > I do not advocate this use though, as I think commit messages should be > more wordy. > >> >> 2. Many users are not familiar with Vim, and do not understand how to >> modify, save, and exit. It is not very considerate to require a user >> to learn Vim in order to finish a commit that they are in the middle >> of. > > That is true, but vi is like the most available editor as a relict > from ancient times; > as you are on Windows, maybe notepad is the best on that platform. > > Maybe file a bug/issue at https://github.com/git-for-windows to change > the default? > >> >> The existing behavior should be optional, and there should be two new options: >> >> 1. Use a simple inline prompt for a commit message (in the same way >> Git might prompt for a username). >> >> 2. Automatically assign names for commits in the form of "Merged x into y". ``` ## Junio C Hamano, 2016-10-27 22:46 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/xmqqwpgt4dgj.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` John Rood writes: > On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller wrote: >> On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: >>> 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. ``` ## John Rood, 2016-10-27 22:48 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/CALj-rGdTfYYn1Nnksh%3DWijkJxknBUeqci3i3uujH8yzcE1z_8g%40mail.gmail.com In-Reply-To: ``` What I'm really seeking is not a make-shift solution for myself, but an intuitive solution for the novice user-base at large. On Thu, Oct 27, 2016 at 5:27 PM, Junio C Hamano wrote: > John Rood writes: > >> I suppose I can do git config --global core.editor notepad >> However, this really only addresses my second concern. >> >> My first concern is that using a text editor at all seems like >> overkill in many scenarios. > > Nobody stops you from writing a "type whatever you want; I won't let > you edit any mistakes as I am not even a text editor; just hit > RETURN when you are done, as you can only write a single line" > program and set it as your GIT_EDITOR. > > I do not know what would happen when you need "git commit --amend", > though. ``` ## Junio C Hamano, 2016-10-27 22:51 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/xmqqshrh4d91.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` John Rood writes: [administrivia: do not top post] > What I'm really seeking is not a make-shift solution for myself, but > an intuitive solution for the novice user-base at large. Well, there are -m and --no-edit. Recording commits with useless single liner is a bad habit to get into, and change to encourage novice user-base at large to do so is not a good idea. ``` ## John Rood, 2016-10-27 23:16 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/CALj-rGfa5qWHiR42ggN3nWS56SGKHbcLttcyO-zLsSY6BfFifQ%40mail.gmail.com In-Reply-To: ``` Thanks. I wasn't aware of --no-edit, but that is indeed exactly what I was looking for. I think your point about encouraging users to make good use of commit messages is good. My concern though is that vim isn't encouraging users to leave good messages as much as it is scaring them away from leaving messages at all. On Thu, Oct 27, 2016 at 5:51 PM, Junio C Hamano wrote: > John Rood writes: > > [administrivia: do not top post] > >> What I'm really seeking is not a make-shift solution for myself, but >> an intuitive solution for the novice user-base at large. > > Well, there are -m and --no-edit. Recording commits with useless > single liner is a bad habit to get into, and change to encourage > novice user-base at large to do so is not a good idea. ``` ## David Lang, 2016-10-27 23:24 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.02.1610271623260.4123%40nftneq.ynat.uz In-Reply-To: ``` On Thu, 27 Oct 2016, John Rood wrote: > Thanks, I think changing the default for windows is a good idea. notepad doesn't work well with unix line endings, wordpad handles the files much more cleanly. David Lang ``` ## Johannes Schindelin, 2016-10-28 08:49 Subject: Re: feature request Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.20.1610281047420.3264%40virtualbox In-Reply-To: ``` Hi, On Thu, 27 Oct 2016, David Lang wrote: > On Thu, 27 Oct 2016, John Rood wrote: > > > Thanks, I think changing the default for windows is a good idea. > > notepad doesn't work well with unix line endings, wordpad handles the files > much more cleanly. That is why we have a `notepad` helper in Git for Windows that converts line endings transparently before and after calling the real notepad.exe. Ciao, Johannes ``` ## Philip Oakley, 2016-10-28 12:54 Subject: Re: feature request Message-ID: <27B37F6A6F2946CEB274CC85CB43B1F2@PhilipOakley> URL: https://gitlist.dev/e/27B37F6A6F2946CEB274CC85CB43B1F2%40PhilipOakley In-Reply-To: ``` From: "David Lang" > On Thu, 27 Oct 2016, John Rood wrote: > >> Thanks, I think changing the default for windows is a good idea. > > notepad doesn't work well with unix line endings, wordpad handles the > files much more cleanly. > > David Lang > Notepad++ does work well, but isn't a standard part of Windows. [core] editor = 'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noplugin .. is one of the standard StackOverflow recipes. -- Philip ```