{"thread":{"id":"54876","subject":"Git Feature Request (Commit Message editing directly from interactive rebase control file)","startedAt":"2020-12-23T23:08:51Z","lastAt":"2020-12-24T04:25:17Z","messageCount":5,"participants":["Mike McLean","Junio C Hamano","brian m. carlson","Theodore Y. Ts'o"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"412958","messageId":"CAM0jFOfvNFva98PNjO33HW3Y4+L1SufvEHQYzwGLHgOkfhmUDQ@mail.gmail.com","threadId":"54876","inReplyTo":"CAM0jFOfx+vxvUAqZqnxeOvGmn0F0Q6vyTKWPjtsSh1bmq__SsQ@mail.gmail.com","subject":"Git Feature Request (Commit Message editing directly from interactive rebase control file)","fromName":"Mike McLean","fromEmail":"stixmclean@googlemail.com","sentAt":"2020-12-23T23:07:43Z","receivedAt":"2020-12-23T23:08:51Z","isPatch":false,"sender":{"key":"stixmclean@googlemail.com","avatar":"https://gravatar.com/avatar/429ebb046116546906581c5e40a055b9be286775620cae8af1a399d7a8bea15a?d=mp&s=160"},"body":"I initially raised this as a FR with my git UI of choice, and was told\nthat it was actually something that git itself would need to do ...\nand that the standard way to raise Feature Requests was to email this\nlist.\n\nApologies if that's not actually what I should be doing - please let\nme know if this is not an intended use.\n\n=-=-=-=-=-=-=-=-=-=\nWhen you do an interactive rebase, you are presented with a file\nlisting all the commit hashes, their current message, and the\ncommand/operation to perform.\n\nTo edit the commit message you set operation `r` and then are later\ngiven the opportunity to set the message. But that control file is\nonly using the commit hashes to determine which commit is being\nreferenced - the message text in that file isn't being used to\nidentify the message.\n\nSo can we allow the user to (optionally) set the new message directly\nin that file?\n\nIt would make the flow a lot quicker (don't have to open a new editor\ninstance each time.), and would make it a lot easier to make similar\nchanges to a bunch of commits (e.g. prefixing them all with Ticket\nnumber, or fixing a consistent typo in a bunch of commits.)\n\nIndicator that the commit-rename should use the text in the control\nfile (rather than the later editor prompt) could either be A) a new\ncommand (rename-inline, or similar) or B) existing rename command +\n\"the text on this line is different from the text on the original\ncommit\".\n\nObviously this wouldn't support multiline commit messages - those\nwould still use the existing workflow, but adding this new feature\nwouldn't impinge upon them, so they've not lost anything.\n\nAm happy to suggest names and/or shorthand keys for it, if the idea is\nacceptable.\n\nYours,\nBrondahl\n"},{"id":"412962","messageId":"xmqqh7oc5c96.fsf@gitster.c.googlers.com","threadId":"54876","inReplyTo":"CAM0jFOfvNFva98PNjO33HW3Y4+L1SufvEHQYzwGLHgOkfhmUDQ@mail.gmail.com","subject":"Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-23T23:33:09Z","receivedAt":"2020-12-23T23:34:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike McLean <stixmclean@googlemail.com> writes:\n\n> I initially raised this as a FR with my git UI of choice, and was told\n> that it was actually something that git itself would need to do ...\n> and that the standard way to raise Feature Requests was to email this\n> list.\n>\n> Apologies if that's not actually what I should be doing - please let\n> me know if this is not an intended use.\n>\n> =-=-=-=-=-=-=-=-=-=\n> When you do an interactive rebase, you are presented with a file\n> listing all the commit hashes, their current message, and the\n> command/operation to perform.\n\nEach commit is shown only with their title, but does not show the\nfull message, exactly because the text is merely there to help the\nuser identify which commits are being shown and manipulated.\n\n> ...\n> So can we allow the user to (optionally) set the new message directly\n> in that file?\n\nI suspect that such a \"feature\" would encourage people to use a\nsingle liner commit log message, that is only the title, so that\nthey do not have to worry about the real log message in the body.\nAnd it does not particularly feel a good behaviour that we'd want to\nencourage.  So, I dunno.\n"},{"id":"412967","messageId":"X+PbbVNIspvJx/yE@camp.crustytoothpaste.net","threadId":"54876","inReplyTo":"CAM0jFOfvNFva98PNjO33HW3Y4+L1SufvEHQYzwGLHgOkfhmUDQ@mail.gmail.com","subject":"Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-12-24T00:06:05Z","receivedAt":"2020-12-24T00:06:53Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-12-23 at 23:07:43, Mike McLean wrote:\n> Indicator that the commit-rename should use the text in the control\n> file (rather than the later editor prompt) could either be A) a new\n> command (rename-inline, or similar) or B) existing rename command +\n> \"the text on this line is different from the text on the original\n> commit\".\n> \n> Obviously this wouldn't support multiline commit messages - those\n> would still use the existing workflow, but adding this new feature\n> wouldn't impinge upon them, so they've not lost anything.\n\nI know people tend to do this quite frequently, but it's extremely\nuncommon for me to write such a message.  I normally write a reasonably\nverbose commit message, and in the vast majority of the cases where the\nchange is so trivial that I write a single-line commit message, I'm on a\nproject with sign-offs, so this wouldn't work there.\n\nThat doesn't mean that this couldn't be useful in some cases, but I\nthink we're likely to encourage single-line commit messages, which I\ndon't think we want to do in the general case, or cause user confusion\nwhen their commit message inline is either (a) truncated unexpectedly or\n(b) not honored because the message is already multiline.  So I feel\nlike such a feature is a foot-gun waiting to happen.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"412970","messageId":"CAM0jFOfA2HH9gC0RRX52NSEPGcsCg_7fhVUYt8cmM8G5=nhtpg@mail.gmail.com","threadId":"54876","inReplyTo":"X+PbbVNIspvJx/yE@camp.crustytoothpaste.net","subject":"Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)","fromName":"Mike McLean","fromEmail":"stixmclean@googlemail.com","sentAt":"2020-12-24T00:17:26Z","receivedAt":"2020-12-24T00:18:20Z","isPatch":false,"sender":{"key":"stixmclean@googlemail.com","avatar":"https://gravatar.com/avatar/429ebb046116546906581c5e40a055b9be286775620cae8af1a399d7a8bea15a?d=mp&s=160"},"body":"These seem fair concerns.\n\nDetailed multi-line commits are something that I know exist, but I've\nnever seen much need or use for, personally, and no project teams I've\never worked on have used them.\nBut if that's the declared preferred-approach then I agree that this\nfeature would be actively detrimental to that and thus is not\nappropriate.\n\nThanks for the responses!\n\nOn Thu, Dec 24, 2020 at 12:06 AM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> On 2020-12-23 at 23:07:43, Mike McLean wrote:\n> > Indicator that the commit-rename should use the text in the control\n> > file (rather than the later editor prompt) could either be A) a new\n> > command (rename-inline, or similar) or B) existing rename command +\n> > \"the text on this line is different from the text on the original\n> > commit\".\n> >\n> > Obviously this wouldn't support multiline commit messages - those\n> > would still use the existing workflow, but adding this new feature\n> > wouldn't impinge upon them, so they've not lost anything.\n>\n> I know people tend to do this quite frequently, but it's extremely\n> uncommon for me to write such a message.  I normally write a reasonably\n> verbose commit message, and in the vast majority of the cases where the\n> change is so trivial that I write a single-line commit message, I'm on a\n> project with sign-offs, so this wouldn't work there.\n>\n> That doesn't mean that this couldn't be useful in some cases, but I\n> think we're likely to encourage single-line commit messages, which I\n> don't think we want to do in the general case, or cause user confusion\n> when their commit message inline is either (a) truncated unexpectedly or\n> (b) not honored because the message is already multiline.  So I feel\n> like such a feature is a foot-gun waiting to happen.\n> --\n> brian m. carlson (he/him or they/them)\n> Houston, Texas, US\n"},{"id":"412981","messageId":"X+QXYhSnuIOdeeCv@mit.edu","threadId":"54876","inReplyTo":"CAM0jFOfA2HH9gC0RRX52NSEPGcsCg_7fhVUYt8cmM8G5=nhtpg@mail.gmail.com","subject":"Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2020-12-24T04:21:54Z","receivedAt":"2020-12-24T04:25:17Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Dec 24, 2020 at 12:17:26AM +0000, Mike McLean wrote:\n> These seem fair concerns.\n> \n> Detailed multi-line commits are something that I know exist, but I've\n> never seen much need or use for, personally, and no project teams I've\n> ever worked on have used them.\n> But if that's the declared preferred-approach then I agree that this\n> feature would be actively detrimental to that and thus is not\n> appropriate.\n\nThe preferred approach is a single line summary of the commit,\nfollowed by a body of text explaining the \"why\" of a commit.  In some\ncases, the \"why\" may be several paragraphs explaining a one line\nchange.  For example, in this commit, see how much explanation was\ngiven for a single _character_ change:\n\nhttps://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=5a3b590d4b2db187faa6f06adc9a53d6199fb1f9\n\nHaving detailed messages is critically important; since even the\ncommit author is not likely to remember all of the details of a\nparticular change a even few months later --- and when examining\nchanges that was made by others, sometimes years latter, context can\nbe critical to understanding what was going on.\n\nCertainly, if I were reviewing some public git repository belonging to\nsomeone who was interviewing for a position at $WORK, and they had one\nline commit descriptions, I personally would consider that to be a\nsignal that their software engineering skills might be lacking.\nHaving good commit descriptions is right up there with having good\nregression tests and having a second engineer do code reviews (which\ninclude reviewing the commit description for sufficiency) as part of\nbasic software development practice.\n\nCheers,\n\n\t\t\t\t\t- Ted\n"}]}