{"thread":{"id":"44384","subject":"feature request","startedAt":"2016-10-27T21:56:02Z","lastAt":"2016-10-28T16:32:06Z","messageCount":14,"participants":["John Rood","Stefan Beller","Junio C Hamano","David Lang","Johannes Schindelin","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"305002","messageId":"CALj-rGeoT_mpmuw8Put=6eRhzf-r2WUohu_Kd-wnpc=BvO5joA@mail.gmail.com","threadId":"44384","inReplyTo":null,"subject":"feature request","fromName":"John Rood","fromEmail":"mr.john.rood@gmail.com","sentAt":"2016-10-27T21:55:56Z","receivedAt":"2016-10-27T21:56:02Z","isPatch":false,"sender":{"key":"mr.john.rood@gmail.com","avatar":"https://gravatar.com/avatar/7d2af963b361d158a37938d662661cc74f00437b86ed837ab2bf45fb28bbfe3b?d=mp&s=160"},"body":"Users should be able to configure Git to not send them into a Vim editor.\n\nWhen users pull commits, and a new commit needs to be created for a\nmerge, Git's current way of determining a commit message is to send\nthe user into a Vim window so that they can write a message. There are\n2 reasons why this might not be the ideal way to prompt for a commit\nmessage.\n\n1. Many users are used to writing concise one-line commit messages and\nwould not expect to save a commit message in a multi-line file. Some\nusers will wonder why they are in a text editor or which file they are\nediting. Others may not, in fact, realize at all that a text editor is\nwhat they are in.\n\n2. Many users are not familiar with Vim, and do not understand how to\nmodify, save, and exit. It is not very considerate to require a user\nto learn Vim in order to finish a commit that they are in the middle\nof.\n\nThe existing behavior should be optional, and there should be two new options:\n\n1. Use a simple inline prompt for a commit message (in the same way\nGit might prompt for a username).\n\n2. Automatically assign names for commits in the form of \"Merged x into y\".\n"},{"id":"305004","messageId":"CAGZ79kZAfqxB699MOs6A6RL==Ku-qF7ABiW=eA+TSrqK+8e_sA@mail.gmail.com","threadId":"44384","inReplyTo":"CALj-rGeoT_mpmuw8Put=6eRhzf-r2WUohu_Kd-wnpc=BvO5joA@mail.gmail.com","subject":"Re: feature request","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-27T22:01:13Z","receivedAt":"2016-10-27T22:01:19Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> wrote:\n> Users should be able to configure Git to not send them into a Vim editor.\n\nSee https://git-scm.com/docs/git-var\n\nGIT_EDITOR\n\nText editor for use by Git commands. The value is meant to be interpreted\nby the shell when it is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE,\n\"C:\\Program Files\\Vim\\gvim.exe\" --nofork. The order of preference is the\n$GIT_EDITOR environment variable, then core.editor configuration, then\n$VISUAL, then $EDITOR, and then the default chosen at compile time,\nwhich is usually vi.\n\n\nSo maybe\n\n    git config --global core.editor \"nano\"\n\nhelps in your case?\n"},{"id":"305005","messageId":"CALj-rGeMHyN6Xhc0_KCChmWL4BDyF-ZJYdipbe1_yNvznrYPVA@mail.gmail.com","threadId":"44384","inReplyTo":"CAGZ79kZAfqxB699MOs6A6RL==Ku-qF7ABiW=eA+TSrqK+8e_sA@mail.gmail.com","subject":"Re: feature request","fromName":"John Rood","fromEmail":"mr.john.rood@gmail.com","sentAt":"2016-10-27T22:05:43Z","receivedAt":"2016-10-27T22:05:48Z","isPatch":false,"sender":{"key":"mr.john.rood@gmail.com","avatar":"https://gravatar.com/avatar/7d2af963b361d158a37938d662661cc74f00437b86ed837ab2bf45fb28bbfe3b?d=mp&s=160"},"body":"Unfortunately, in my case I'm on windows (my company's choice, not mine).\n\nOn Thu, Oct 27, 2016 at 5:01 PM, Stefan Beller <sbeller@google.com> wrote:\n> On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> wrote:\n>> Users should be able to configure Git to not send them into a Vim editor.\n>\n> See https://git-scm.com/docs/git-var\n>\n> GIT_EDITOR\n>\n> Text editor for use by Git commands. The value is meant to be interpreted\n> by the shell when it is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE,\n> \"C:\\Program Files\\Vim\\gvim.exe\" --nofork. The order of preference is the\n> $GIT_EDITOR environment variable, then core.editor configuration, then\n> $VISUAL, then $EDITOR, and then the default chosen at compile time,\n> which is usually vi.\n>\n>\n> So maybe\n>\n>     git config --global core.editor \"nano\"\n>\n> helps in your case?\n"},{"id":"305009","messageId":"CALj-rGfsy+KA=dsd+wobMiVOWHK1GU=dZRcQWtMoXwtBrMYPLg@mail.gmail.com","threadId":"44384","inReplyTo":"CALj-rGeMHyN6Xhc0_KCChmWL4BDyF-ZJYdipbe1_yNvznrYPVA@mail.gmail.com","subject":"Re: feature request","fromName":"John Rood","fromEmail":"mr.john.rood@gmail.com","sentAt":"2016-10-27T22:24:08Z","receivedAt":"2016-10-27T22:24:42Z","isPatch":false,"sender":{"key":"mr.john.rood@gmail.com","avatar":"https://gravatar.com/avatar/7d2af963b361d158a37938d662661cc74f00437b86ed837ab2bf45fb28bbfe3b?d=mp&s=160"},"body":"I suppose I can do git config --global core.editor notepad\nHowever, this really only addresses my second concern.\n\nMy first concern is that using a text editor at all seems like\noverkill in many scenarios.\nFor that reason, I still think the other two options I mentioned would\nbe beneficial.\n\nOn Thu, Oct 27, 2016 at 5:05 PM, John Rood <mr.john.rood@gmail.com> wrote:\n> Unfortunately, in my case I'm on windows (my company's choice, not mine).\n>\n> On Thu, Oct 27, 2016 at 5:01 PM, Stefan Beller <sbeller@google.com> wrote:\n>> On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> wrote:\n>>> Users should be able to configure Git to not send them into a Vim editor.\n>>\n>> See https://git-scm.com/docs/git-var\n>>\n>> GIT_EDITOR\n>>\n>> Text editor for use by Git commands. The value is meant to be interpreted\n>> by the shell when it is used. Examples: ~/bin/vi, $SOME_ENVIRONMENT_VARIABLE,\n>> \"C:\\Program Files\\Vim\\gvim.exe\" --nofork. The order of preference is the\n>> $GIT_EDITOR environment variable, then core.editor configuration, then\n>> $VISUAL, then $EDITOR, and then the default chosen at compile time,\n>> which is usually vi.\n>>\n>>\n>> So maybe\n>>\n>>     git config --global core.editor \"nano\"\n>>\n>> helps in your case?\n"},{"id":"305010","messageId":"xmqq1sz15swv.fsf@gitster.mtv.corp.google.com","threadId":"44384","inReplyTo":"CALj-rGfsy+KA=dsd+wobMiVOWHK1GU=dZRcQWtMoXwtBrMYPLg@mail.gmail.com","subject":"Re: feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-27T22:27:44Z","receivedAt":"2016-10-27T22:27:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Rood <mr.john.rood@gmail.com> writes:\n\n> I suppose I can do git config --global core.editor notepad\n> However, this really only addresses my second concern.\n>\n> My first concern is that using a text editor at all seems like\n> overkill in many scenarios.\n\nNobody stops you from writing a \"type whatever you want; I won't let\nyou edit any mistakes as I am not even a text editor; just hit\nRETURN when you are done, as you can only write a single line\"\nprogram and set it as your GIT_EDITOR.\n\nI do not know what would happen when you need \"git commit --amend\",\nthough.\n"},{"id":"305012","messageId":"CAGZ79ka7BvaW2pkjeXe68yKHFq6JsH__x2cXoe6U4tRmZ0rY1A@mail.gmail.com","threadId":"44384","inReplyTo":"CALj-rGeoT_mpmuw8Put=6eRhzf-r2WUohu_Kd-wnpc=BvO5joA@mail.gmail.com","subject":"Re: feature request","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-27T22:30:58Z","receivedAt":"2016-10-27T22:31:07Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> wrote:\n> Users should be able to configure Git to not send them into a Vim editor.\n>\n> When users pull commits, and a new commit needs to be created for a\n> merge, Git's current way of determining a commit message is to send\n> the user into a Vim window so that they can write a message. There are\n> 2 reasons why this might not be the ideal way to prompt for a commit\n> message.\n>\n> 1. Many users are used to writing concise one-line commit messages and\n> would not expect to save a commit message in a multi-line file. Some\n> users will wonder why they are in a text editor or which file they are\n> editing. Others may not, in fact, realize at all that a text editor is\n> what they are in.\n\nLook at the -m option of git commit,\n\ngit commit -a -m \"look a commit with no editor, and a precise one line message\"\n\nI do not advocate this use though, as I think commit messages should be\nmore wordy.\n\n>\n> 2. Many users are not familiar with Vim, and do not understand how to\n> modify, save, and exit. It is not very considerate to require a user\n> to learn Vim in order to finish a commit that they are in the middle\n> of.\n\nThat is true, but vi is like the most available editor as a relict\nfrom ancient times;\nas you are on Windows, maybe notepad is the best on that platform.\n\nMaybe file a bug/issue at https://github.com/git-for-windows to change\nthe default?\n\n>\n> The existing behavior should be optional, and there should be two new options:\n>\n> 1. Use a simple inline prompt for a commit message (in the same way\n> Git might prompt for a username).\n>\n> 2. Automatically assign names for commits in the form of \"Merged x into y\".\n"},{"id":"305020","messageId":"CALj-rGfAyimf0nFFcDHVHUgj8PQaz6Cvoz_PQfqdhr=QJEpbRw@mail.gmail.com","threadId":"44384","inReplyTo":"CAGZ79ka7BvaW2pkjeXe68yKHFq6JsH__x2cXoe6U4tRmZ0rY1A@mail.gmail.com","subject":"Re: feature request","fromName":"John Rood","fromEmail":"mr.john.rood@gmail.com","sentAt":"2016-10-27T22:44:20Z","receivedAt":"2016-10-27T22:44:26Z","isPatch":false,"sender":{"key":"mr.john.rood@gmail.com","avatar":"https://gravatar.com/avatar/7d2af963b361d158a37938d662661cc74f00437b86ed837ab2bf45fb28bbfe3b?d=mp&s=160"},"body":"Thanks, I think changing the default for windows is a good idea.\n\nThe -m indeed accomplishes one-line messages when you are voluntarily\ndoing a commit. However, the scenario I mentioned is \"When users pull\ncommits, and a new commit needs to be created for the merge\"  In this\nsituation, the user isn't issuing the \"git commit\" command, and so\nhe/she doesn't have the opportunity to use the -m flag.\n\nOn Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller <sbeller@google.com> wrote:\n> On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> wrote:\n>> Users should be able to configure Git to not send them into a Vim editor.\n>>\n>> When users pull commits, and a new commit needs to be created for a\n>> merge, Git's current way of determining a commit message is to send\n>> the user into a Vim window so that they can write a message. There are\n>> 2 reasons why this might not be the ideal way to prompt for a commit\n>> message.\n>>\n>> 1. Many users are used to writing concise one-line commit messages and\n>> would not expect to save a commit message in a multi-line file. Some\n>> users will wonder why they are in a text editor or which file they are\n>> editing. Others may not, in fact, realize at all that a text editor is\n>> what they are in.\n>\n> Look at the -m option of git commit,\n>\n> git commit -a -m \"look a commit with no editor, and a precise one line message\"\n>\n> I do not advocate this use though, as I think commit messages should be\n> more wordy.\n>\n>>\n>> 2. Many users are not familiar with Vim, and do not understand how to\n>> modify, save, and exit. It is not very considerate to require a user\n>> to learn Vim in order to finish a commit that they are in the middle\n>> of.\n>\n> That is true, but vi is like the most available editor as a relict\n> from ancient times;\n> as you are on Windows, maybe notepad is the best on that platform.\n>\n> Maybe file a bug/issue at https://github.com/git-for-windows to change\n> the default?\n>\n>>\n>> The existing behavior should be optional, and there should be two new options:\n>>\n>> 1. Use a simple inline prompt for a commit message (in the same way\n>> Git might prompt for a username).\n>>\n>> 2. Automatically assign names for commits in the form of \"Merged x into y\".\n"},{"id":"305021","messageId":"xmqqwpgt4dgj.fsf@gitster.mtv.corp.google.com","threadId":"44384","inReplyTo":"CALj-rGfAyimf0nFFcDHVHUgj8PQaz6Cvoz_PQfqdhr=QJEpbRw@mail.gmail.com","subject":"Re: feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-27T22:46:52Z","receivedAt":"2016-10-27T22:47:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Rood <mr.john.rood@gmail.com> writes:\n\n> On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller <sbeller@google.com> wrote:\n>> On Thu, Oct 27, 2016 at 2:55 PM, John Rood <mr.john.rood@gmail.com> wrote:\n>>> Users should be able to configure Git to not send them into a Vim editor.\n>>>\n>>> When users pull commits, and a new commit needs to be created for a\n>>> merge, Git's current way of determining a commit message is to send\n>>> the user into a Vim window so that they can write a message. There are\n>>> 2 reasons why this might not be the ideal way to prompt for a commit\n>>> message.\n>>>\n>>> 1. Many users are used to writing concise one-line commit messages and\n>>> would not expect to save a commit message in a multi-line file. Some\n>>> users will wonder why they are in a text editor or which file they are\n>>> editing. Others may not, in fact, realize at all that a text editor is\n>>> what they are in.\n>>\n>> Look at the -m option of git commit,\n>>\n\n[administrivia: do not top post]\n\n> Thanks, I think changing the default for windows is a good idea.\n>\n> The -m indeed accomplishes one-line messages when you are voluntarily\n> doing a commit. However, the scenario I mentioned is \"When users pull\n> commits, and a new commit needs to be created for the merge\"  In this\n> situation, the user isn't issuing the \"git commit\" command, and so\n> he/she doesn't have the opportunity to use the -m flag.\n\nThere is --no-edit there.\n\n\n"},{"id":"305022","messageId":"CALj-rGdTfYYn1Nnksh=WijkJxknBUeqci3i3uujH8yzcE1z_8g@mail.gmail.com","threadId":"44384","inReplyTo":"xmqq1sz15swv.fsf@gitster.mtv.corp.google.com","subject":"Re: feature request","fromName":"John Rood","fromEmail":"mr.john.rood@gmail.com","sentAt":"2016-10-27T22:48:47Z","receivedAt":"2016-10-27T22:48:55Z","isPatch":false,"sender":{"key":"mr.john.rood@gmail.com","avatar":"https://gravatar.com/avatar/7d2af963b361d158a37938d662661cc74f00437b86ed837ab2bf45fb28bbfe3b?d=mp&s=160"},"body":"What I'm really seeking is not a make-shift solution for myself, but\nan intuitive solution for the novice user-base at large.\n\nOn Thu, Oct 27, 2016 at 5:27 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> John Rood <mr.john.rood@gmail.com> writes:\n>\n>> I suppose I can do git config --global core.editor notepad\n>> However, this really only addresses my second concern.\n>>\n>> My first concern is that using a text editor at all seems like\n>> overkill in many scenarios.\n>\n> Nobody stops you from writing a \"type whatever you want; I won't let\n> you edit any mistakes as I am not even a text editor; just hit\n> RETURN when you are done, as you can only write a single line\"\n> program and set it as your GIT_EDITOR.\n>\n> I do not know what would happen when you need \"git commit --amend\",\n> though.\n"},{"id":"305023","messageId":"xmqqshrh4d91.fsf@gitster.mtv.corp.google.com","threadId":"44384","inReplyTo":"CALj-rGdTfYYn1Nnksh=WijkJxknBUeqci3i3uujH8yzcE1z_8g@mail.gmail.com","subject":"Re: feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-27T22:51:22Z","receivedAt":"2016-10-27T22:51:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Rood <mr.john.rood@gmail.com> writes:\n\n[administrivia: do not top post]\n\n> What I'm really seeking is not a make-shift solution for myself, but\n> an intuitive solution for the novice user-base at large.\n\nWell, there are -m and --no-edit.  Recording commits with useless\nsingle liner is a bad habit to get into, and change to encourage\nnovice user-base at large to do so is not a good idea.\n"},{"id":"305027","messageId":"CALj-rGfa5qWHiR42ggN3nWS56SGKHbcLttcyO-zLsSY6BfFifQ@mail.gmail.com","threadId":"44384","inReplyTo":"xmqqshrh4d91.fsf@gitster.mtv.corp.google.com","subject":"Re: feature request","fromName":"John Rood","fromEmail":"mr.john.rood@gmail.com","sentAt":"2016-10-27T23:16:50Z","receivedAt":"2016-10-27T23:16:56Z","isPatch":false,"sender":{"key":"mr.john.rood@gmail.com","avatar":"https://gravatar.com/avatar/7d2af963b361d158a37938d662661cc74f00437b86ed837ab2bf45fb28bbfe3b?d=mp&s=160"},"body":"Thanks. I wasn't aware of --no-edit, but that is indeed exactly what I\nwas looking for.\n\nI think your point about encouraging users to make good use of commit\nmessages is good.\nMy concern though is that vim isn't encouraging users to leave good\nmessages as much as it is scaring them away from leaving messages at\nall.\n\n\nOn Thu, Oct 27, 2016 at 5:51 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> John Rood <mr.john.rood@gmail.com> writes:\n>\n> [administrivia: do not top post]\n>\n>> What I'm really seeking is not a make-shift solution for myself, but\n>> an intuitive solution for the novice user-base at large.\n>\n> Well, there are -m and --no-edit.  Recording commits with useless\n> single liner is a bad habit to get into, and change to encourage\n> novice user-base at large to do so is not a good idea.\n"},{"id":"305030","messageId":"alpine.DEB.2.02.1610271623260.4123@nftneq.ynat.uz","threadId":"44384","inReplyTo":"CALj-rGfAyimf0nFFcDHVHUgj8PQaz6Cvoz_PQfqdhr=QJEpbRw@mail.gmail.com","subject":"Re: feature request","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2016-10-27T23:24:15Z","receivedAt":"2016-10-27T23:32:51Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 27 Oct 2016, John Rood wrote:\n\n> Thanks, I think changing the default for windows is a good idea.\n\nnotepad doesn't work well with unix line endings, wordpad handles the files much \nmore cleanly.\n\nDavid Lang\n"},{"id":"305047","messageId":"alpine.DEB.2.20.1610281047420.3264@virtualbox","threadId":"44384","inReplyTo":"alpine.DEB.2.02.1610271623260.4123@nftneq.ynat.uz","subject":"Re: feature request","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-10-28T08:49:05Z","receivedAt":"2016-10-28T08:49:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 27 Oct 2016, David Lang wrote:\n\n> On Thu, 27 Oct 2016, John Rood wrote:\n> \n> > Thanks, I think changing the default for windows is a good idea.\n> \n> notepad doesn't work well with unix line endings, wordpad handles the files\n> much more cleanly.\n\nThat is why we have a `notepad` helper in Git for Windows that converts\nline endings transparently before and after calling the real notepad.exe.\n\nCiao,\nJohannes\n"},{"id":"305067","messageId":"27B37F6A6F2946CEB274CC85CB43B1F2@PhilipOakley","threadId":"44384","inReplyTo":"alpine.DEB.2.02.1610271623260.4123@nftneq.ynat.uz","subject":"Re: feature request","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-10-28T12:54:59Z","receivedAt":"2016-10-28T16:32:06Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"David Lang\" <david@lang.hm>\n> On Thu, 27 Oct 2016, John Rood wrote:\n>\n>> Thanks, I think changing the default for windows is a good idea.\n>\n> notepad doesn't work well with unix line endings, wordpad handles the \n> files much more cleanly.\n>\n> David Lang\n>\n\nNotepad++ does work well, but isn't a standard part of Windows.\n\n[core]\n editor = 'C:/Program \nFiles/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noplugin\n\n.. is one of the standard StackOverflow recipes.\n--\nPhilip \n\n"}]}