{"thread":{"id":"57693","subject":"Make commit messages optional","startedAt":"2022-04-08T03:35:12Z","lastAt":"2022-04-14T17:25:39Z","messageCount":29,"participants":["jurgen_gjoncari@icloud.com","Christian Couder","Philip Oakley","Ævar Arnfjörð Bjarmason","Phillip Susi","Erik Cervin Edin","brian m. carlson","rsbecker@nexbridge.com","Michal Suchánek","Tao Klerks","demerphq","Junio C Hamano","tytso","Jonathan Nieder","Theodore Ts'o"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"453310","messageId":"7ED89912-2E10-4356-9C61-14B90EC0719C@icloud.com","threadId":"57693","inReplyTo":null,"subject":"Make commit messages optional","fromName":"","fromEmail":"jurgen_gjoncari@icloud.com","sentAt":"2022-04-08T03:35:04Z","receivedAt":"2022-04-08T03:35:12Z","isPatch":false,"sender":{"key":"jurgen_gjoncari@icloud.com","avatar":null},"body":"I think that often commit messages are unnecessary. I propose that by default a user should be able to commit without a message. \n\nI don't think this would be a problem from the UX point of view, because a user could get a lot of information about a change, from the history of the GitHub repository, such as from the time of change, and seeing the diff. \n\nI think that making commit messages options wouldn't even be a problem for retro compatibility because the feature would remain still functional for those who would want to use it. "},{"id":"453315","messageId":"CAP8UFD2Tk-FuGcFN0DEKK6g3O8G=SGuU99FPRRqPM_-39i9t0A@mail.gmail.com","threadId":"57693","inReplyTo":"7ED89912-2E10-4356-9C61-14B90EC0719C@icloud.com","subject":"Re: Make commit messages optional","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2022-04-08T08:02:21Z","receivedAt":"2022-04-08T08:02:54Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Apr 8, 2022 at 6:10 AM <jurgen_gjoncari@icloud.com> wrote:\n>\n> I think that often commit messages are unnecessary. I propose that by default a user should be able to commit without a message.\n\nWe prefer to encourage users to do the right thing by default and\nprovide a commit message. We think that good software development\npractices should be encouraged and that providing a good commit\nmessage is good software development practice.\n\n> I don't think this would be a problem from the UX point of view, because a user could get a lot of information about a change, from the history of the GitHub repository, such as from the time of change, and seeing the diff.\n\nWhat about `git log --oneline`?\n\n> I think that making commit messages options wouldn't even be a problem for retro compatibility because the feature would remain still functional for those who would want to use it.\n\nYeah, there is no compatibility issue because `git commit` already has\nan `--allow-empty-message` option, so empty commit messages are\nalready supported. That's not a good reason to make it the default\nthough.\n"},{"id":"453318","messageId":"5d6df8fa-eaea-4ead-e966-8efe60784409@iee.email","threadId":"57693","inReplyTo":"7ED89912-2E10-4356-9C61-14B90EC0719C@icloud.com","subject":"Re: Make commit messages optional","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-04-08T08:15:01Z","receivedAt":"2022-04-08T08:15:08Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Jurgen\n\nOn 08/04/2022 04:35, jurgen_gjoncari@icloud.com wrote:\n> I think that often commit messages are unnecessary. I propose that by default a user should be able to commit without a message. \n>\n> I don't think this would be a problem from the UX point of view, because a user could get a lot of information about a change, from the history of the GitHub repository, such as from the time of change, and seeing the diff. \n>\n> I think that making commit messages options wouldn't even be a problem for retro compatibility because the feature would remain still functional for those who would want to use it. \n\nIsn't this an ideal candidate for an alias that simply passes in the\nempty message?\n\nHowever, it's worth reviewing and doing a retrospective about commit\nmessages and who they are there to inform.\n\nThey (these supposedly informative messages) used to frustrate me many\nyears ago. I already _knew_ what I was doing, and it was 'obvious', what\neven needed saying (so say nothing).\n\nThe Git project's style has been informative in showing how to provide a\nwell focussed concise message that should be understandable to others,\nto your future self, and help clarify one's current understanding of the\nproblem at hand. Often the last point will mean one upgrades the code to\nmeet the real need.\n\n--\nPhilip\n"},{"id":"453328","messageId":"220408.86r167bxra.gmgdl@evledraar.gmail.com","threadId":"57693","inReplyTo":"CAP8UFD2Tk-FuGcFN0DEKK6g3O8G=SGuU99FPRRqPM_-39i9t0A@mail.gmail.com","subject":"Re: Make commit messages optional","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-08T11:26:40Z","receivedAt":"2022-04-08T11:49:51Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 08 2022, Christian Couder wrote:\n\n> On Fri, Apr 8, 2022 at 6:10 AM <jurgen_gjoncari@icloud.com> wrote:\n>>\n>> I think that often commit messages are unnecessary. I propose that by default a user should be able to commit without a message.\n>\n> We prefer to encourage users to do the right thing by default and\n> provide a commit message. We think that good software development\n> practices should be encouraged and that providing a good commit\n> message is good software development practice.\n>\n>> I don't think this would be a problem from the UX point of view,\n>> because a user could get a lot of information about a change, from\n>> the history of the GitHub repository, such as from the time of\n>> change, and seeing the diff.\n>\n> What about `git log --oneline`?\n>\n>> I think that making commit messages options wouldn't even be a problem for retro compatibility because the feature would remain still functional for those who would want to use it.\n>\n> Yeah, there is no compatibility issue because `git commit` already has\n> an `--allow-empty-message` option, so empty commit messages are\n> already supported. That's not a good reason to make it the default\n> though.\n\nI agree that we should do away with the check for the empty commit\nmessage.\n\nI also added --allow-empty-message in the first place, so I'm a bit\nbiased.\n\nNow, anyone who's seen pretty much any of my commits knows I don't have\nmuch of an issue with writing commit messages when it matters.\n\nBut to get around this requirement of git I've got a local alias that\nbasically does:\n\n    git commit -m\"$(line from http://whatthecommit.com/)\"\n\nI could use --allow-empty-message, but I think at some point we still\nhad tooling (git am?) that was annoying to use with it, so I settled on\nthat \"solution\", and muscle memory dies hard (I've got a short alias for\nthis thing)>\n\nIn general I wish git were more helpful and less opinionated. It's fine\nto have sane defaults, or to help users, but e.g. this case I think was\nalways better handled with an advise() or something.\n\nGit is also used in a lot of contexts that aren't \"normal\" software\ndevelopment, e.g. the \"gist\" feature on GitHub creates commits without\ncommit messages.\n\nNow, of course they know about --allow-empty-message, and users *can*\nfind it too. But UX friction is like taxation, you add friction where\nyou want to discourage things, and sometimes users are discouraged\nentirely because you've added that cost. After all you probably know\nbetter, maybe they shouldn't be doing that with the tool. Or they never\ncheck that it *can* be done, and just stop because it's erroring by\ndefault.\n\nBut even if git were only used for software development I think adding\nthis friction *there* is entirely misguided.\n\nIt's perpetuating the notion that there shouldn't be a disconnect\nbetween \"what you commit\" and \"what you push\".\n\nI think one of the best things about git's design is how in most other\nareas we've really leaned into that design ethos. I.e. you can commit\nwhatever train-of-thought garbage you want, but we make it really easy\nto interactively rebase all of that before pushing (or \"finalizing\") it.\n\nWhich, as an aside is a notable difference to the fossil SCM system,\nwhich heavily leans into the exact opposite notion. I.e. that thou shalt\nnot alter work already committed (even if not \"pushed\").\n\nSo I'd really like to see (from someone who's got more interest & time\nto work on this) some change to this default limitation that steered\nusers more towards use cases we actually care about.\n\nE.g. I wouldn't mind if we made pushes start failing (probably guarded\nby appropriate isatty() checks) if the user was pushing content without\ncommit messages, unless some option were overridden, or we could start\nsternly warning about that. Ditto for merging a branch into another one\n(especially if we can see it's the default branch).\n\nAll of those things would actually have some hope of aligning with what\nwe're *actually* trying to encourage.\n\nBut doing this at the point of commits? I think it just amounts to some\nmisguided rear-guard action, and it's actually doing more harm than\ngood.\n\nWe're encouraging users to think that there's a 1=1 mapping between\ncommit message and time of commit/snapshot. If I had to pick one thing\nthat's the difference between a beginner novice git user and someone\nwho's an intermediate/advanced it's knowing that there's a disconnect\nbetween the two, and using it to one's advantage (i.e. rebase -i before\npushing)>\n\nAll that being said I think a perfectly good incremental step would be\nto make --allow-empty-message the default, and just replace it with some\nadvise() instead.\n\nWe could even emit such advise() e.g. if we see the message is shorter\nthan some length, or if there's a big delta between commit message\nlength & diff length. Both of those things would be a lot easier than\nthe suggested \"error on push\" above, and wouldn't require revision\nwalking, just a small change or check in builtin/commit.c.\n\nBut of course any such changes would need to get through list review,\nand I know there's a lot of people who feel quite strongly about this in\nthe opposite direction.\n\nBut I'm also pretty sure that those people are engaged in a proxy war,\nand we should just attack the \"problem\" directly instead. I.e. it's not\na problem that some commit somewhere has an empty message, rather it's\nthat such a commit gets \"propagated\". A better place to check for it is\nthen at the point of point of propagation.\n"},{"id":"453334","messageId":"877d7zfxwp.fsf@vps.thesusis.net","threadId":"57693","inReplyTo":"7ED89912-2E10-4356-9C61-14B90EC0719C@icloud.com","subject":"Re: Make commit messages optional","fromName":"Phillip Susi","fromEmail":"phill@thesusis.net","sentAt":"2022-04-08T14:32:23Z","receivedAt":"2022-04-08T14:32:57Z","isPatch":false,"sender":{"key":"phill@thesusis.net","avatar":null},"body":"\njurgen_gjoncari@icloud.com writes:\n\n> I think that often commit messages are unnecessary. I propose that by\n\nYou would be wrong :)\n"},{"id":"453349","messageId":"CA+JQ7M-uSatD4=HHxaqe4yVAJ5WGuWC_BprX4hnfKSrt6-1GEg@mail.gmail.com","threadId":"57693","inReplyTo":"220408.86r167bxra.gmgdl@evledraar.gmail.com","subject":"Re: Make commit messages optional","fromName":"Erik Cervin Edin","fromEmail":"erik@cervined.in","sentAt":"2022-04-08T19:25:00Z","receivedAt":"2022-04-08T19:25:43Z","isPatch":false,"sender":{"key":"erik@cervined.in","avatar":null},"body":"At the risk of bikeshedding.\n\nThe case in favor of not allowing empty commit messages by default is\nthat most of the time, empty commit messages are useless.\n\nI've written my fair share of poor commit messages (-,..., wip, foo).\nSometimes I've fixed that retroactively, sometimes not. The advantage\nI see with empty commit messages is that it's more ubiquitous to\n\"write something better\" or \"whatever\". The downside is I can't git\nlog --grep '^$' to find them.\n\nOn Fri, Apr 8, 2022 at 7:47 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>\n> I think one of the best things about git's design is how in most other\n> areas we've really leaned into that design ethos. I.e. you can commit\n> whatever train-of-thought garbage you want, but we make it really easy\n> to interactively rebase all of that before pushing (or \"finalizing\") it.\n\nTrue. But this is power-user territory. AFAIK, very few users rebase\n-i and very few tools support interactive rebasing. Those that do\nprobably have no problem aliasing git commit to adapt to that workflow\non their own, without different defaults.\n\n> E.g. I wouldn't mind if we made pushes start failing (probably guarded\n> by appropriate isatty() checks) if the user was pushing content without\n> commit messages, unless some option were overridden, or we could start\n> sternly warning about that. Ditto for merging a branch into another one\n> (especially if we can see it's the default branch).\n\nI could see this being a potentially nice option but also pretty much\n.git/hooks/pre-push.sample but with rev-list --grep '^$'  (which\ndoesn't appear to work)\n\n> it's not\n> a problem that some commit somewhere has an empty message, rather it's\n> that such a commit gets \"propagated\". A better place to check for it is\n> then at the point of point of propagation.\n\nI agree in spirit, but also feel obliged to point out the immutability\nof commit messages in most user workflows. In such workflows, the\npropagation in a sense becomes the point of commiting.\n\nMy experience is that in most typical GUI workflows, the writing of a\ncommit message is not a very high point of friction. These\nenvironments typically instead favor larger commits due to friction of\nstaging/unstaging. In such situations, it's more important to write a\ncommit message that at least says *something*.\n"},{"id":"453354","messageId":"YlC3devsgmv17PnQ@camp.crustytoothpaste.net","threadId":"57693","inReplyTo":"7ED89912-2E10-4356-9C61-14B90EC0719C@icloud.com","subject":"Re: Make commit messages optional","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-04-08T22:30:13Z","receivedAt":"2022-04-08T22:30:29Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n> I think that often commit messages are unnecessary. I propose that by\n> default a user should be able to commit without a message. \n\nThis topic comes up from time to time and you can see the previous\ndiscussion in the archives.  The reasons we haven't done this are\nroughly as follows.\n\nFirst, writing commit messages is a way of communicating to others about\nyour changes, as well as to future you.  In my experience, it is\nsubstantially more important in software engineering to communicate\nclearly and effectively than it is to write code.  The computer will\naccept anything that runs, but when you write code others must read it\nand change it, and they must have the appropriate context behind those\nchanges to evaluate your changes and to make their own in the future.\nWe want to encourage good software engineering practices.\n\nTools like git log use the commit message, and empty commit messages\nmean that viewing the list of commits is completely useless without\nviewing a diff.  This means that functionality such as `git log --graph`\nis just completely broken.  Writing even one line in the commit summary\nmakes a massive difference in the usability of these tools.\n\nUsers who want this behaviour can use --allow-empty-message or create an\nalias with that option.  The functionality already exists.  I use\naliases extensively in my development and I know others do as well, so\nthis shouldn't be an impediment if you're working on projects where this\nis acceptable.\n\n> I don't think this would be a problem from the UX point of view,\n> because a user could get a lot of information about a change, from the\n> history of the GitHub repository, such as from the time of change, and\n> seeing the diff. \n\nI certainly hope when you are writing code that you explain your changes\nsomewhere.  I know some people who use pull requests prefer to do so in\nthe pull request rather than the commit message, but I for one would\nnever accept a change that doesn't contain some sort of explanation\nabout why it's valuable or relevant somewhere.  I am, unfortunately, not\nomniscient, so I need people to communicate their intentions and\ndecisions to me, and the best way to do that is with words.\n\nI should also point out that the GitHub UI is specifically designed to\nshow the commit summary in the history view, so GitHub intends for you\nto write at least one line of helpful text (the summary) in this\ncontext.\n\nOverall, I don't believe your proposal is likely to gain traction here\nfor the reasons I mentioned above, and I personally don't support it.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"453358","messageId":"00ca01d84ba0$dd7ee0c0$987ca240$@nexbridge.com","threadId":"57693","inReplyTo":"YlC3devsgmv17PnQ@camp.crustytoothpaste.net","subject":"RE: Make commit messages optional","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-04-08T23:32:03Z","receivedAt":"2022-04-08T23:32:25Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 8, 2022 6:30 PM, brian m. carlson wrote:\n>On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n>> I think that often commit messages are unnecessary. I propose that by\n>> default a user should be able to commit without a message.\n>\n>This topic comes up from time to time and you can see the previous discussion in\n>the archives.  The reasons we haven't done this are roughly as follows.\n>\n>First, writing commit messages is a way of communicating to others about your\n>changes, as well as to future you.  In my experience, it is substantially more\n>important in software engineering to communicate clearly and effectively than it is\n>to write code.  The computer will accept anything that runs, but when you write\n>code others must read it and change it, and they must have the appropriate\n>context behind those changes to evaluate your changes and to make their own in\n>the future.\n>We want to encourage good software engineering practices.\n>\n>Tools like git log use the commit message, and empty commit messages mean that\n>viewing the list of commits is completely useless without viewing a diff.  This\n>means that functionality such as `git log --graph` is just completely broken.  Writing\n>even one line in the commit summary makes a massive difference in the usability\n>of these tools.\n>\n>Users who want this behaviour can use --allow-empty-message or create an alias\n>with that option.  The functionality already exists.  I use aliases extensively in my\n>development and I know others do as well, so this shouldn't be an impediment if\n>you're working on projects where this is acceptable.\n>\n>> I don't think this would be a problem from the UX point of view,\n>> because a user could get a lot of information about a change, from the\n>> history of the GitHub repository, such as from the time of change, and\n>> seeing the diff.\n>\n>I certainly hope when you are writing code that you explain your changes\n>somewhere.  I know some people who use pull requests prefer to do so in the pull\n>request rather than the commit message, but I for one would never accept a\n>change that doesn't contain some sort of explanation about why it's valuable or\n>relevant somewhere.  I am, unfortunately, not omniscient, so I need people to\n>communicate their intentions and decisions to me, and the best way to do that is\n>with words.\n>\n>I should also point out that the GitHub UI is specifically designed to show the\n>commit summary in the history view, so GitHub intends for you to write at least\n>one line of helpful text (the summary) in this context.\n>\n>Overall, I don't believe your proposal is likely to gain traction here for the reasons I\n>mentioned above, and I personally don't support it.\n\nThe commit message is an essential part of why a change was made, in particular for forensics when something goes wrong, or when you are trying to figure out why you did something. Without a commit message, you are saying, \"yeah, ok, something happened.\" It's up there with reporting a bug saying, \"It doesn't work\", with no additional details - I have customers who do that, and it is not helpful. To be harsh about it, if someone commits something with no or a useless message, I will reject the change with impunity. Not explaining yourself is not helpful to those who come after. It's up there with \"Why did you not document your code, when you used single letter variables and strung the whole program on one line because C (or APL) allows it,\" with an answer along the lines of \"Any decent developer should be able to figure out the code.\" Sorry, but I feel very strongly on the subject that this is not a good idea. If you want to put junk in your commit, that is your business, but expect a significant segment of the population looking at your repo on GitHub to judge harshly. This sounds more like \"I don't want to use a version control system, but I have to for some reason, like HR metrics.\" I know I am being harsh on this, and I apologize in advance for it if I offended anyone, but I would want a way to disable (potentially at build time) this if it ever went forward.\n\nMy $0.04\n--Randall\n\n"},{"id":"453366","messageId":"20220409113244.GX163591@kunlun.suse.cz","threadId":"57693","inReplyTo":"00ca01d84ba0$dd7ee0c0$987ca240$@nexbridge.com","subject":"Re: Make commit messages optional","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2022-04-09T11:32:44Z","receivedAt":"2022-04-09T11:32:51Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:\n> On April 8, 2022 6:30 PM, brian m. carlson wrote:\n> >On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n> >> I think that often commit messages are unnecessary. I propose that by\n> >> default a user should be able to commit without a message.\n> >\n> >This topic comes up from time to time and you can see the previous discussion in\n> >the archives.  The reasons we haven't done this are roughly as follows.\n> >\n> >First, writing commit messages is a way of communicating to others about your\n> >changes, as well as to future you.  In my experience, it is substantially more\n> >important in software engineering to communicate clearly and effectively than it is\n> >to write code.  The computer will accept anything that runs, but when you write\n> >code others must read it and change it, and they must have the appropriate\n> >context behind those changes to evaluate your changes and to make their own in\n> >the future.\n> >We want to encourage good software engineering practices.\n> >\n> >Tools like git log use the commit message, and empty commit messages mean that\n> >viewing the list of commits is completely useless without viewing a diff.  This\n> >means that functionality such as `git log --graph` is just completely broken.  Writing\n> >even one line in the commit summary makes a massive difference in the usability\n> >of these tools.\n> >\n> >Users who want this behaviour can use --allow-empty-message or create an alias\n> >with that option.  The functionality already exists.  I use aliases extensively in my\n> >development and I know others do as well, so this shouldn't be an impediment if\n> >you're working on projects where this is acceptable.\n> >\n> >> I don't think this would be a problem from the UX point of view,\n> >> because a user could get a lot of information about a change, from the\n> >> history of the GitHub repository, such as from the time of change, and\n> >> seeing the diff.\n> >\n> >I certainly hope when you are writing code that you explain your changes\n> >somewhere.  I know some people who use pull requests prefer to do so in the pull\n> >request rather than the commit message, but I for one would never accept a\n> >change that doesn't contain some sort of explanation about why it's valuable or\n> >relevant somewhere.  I am, unfortunately, not omniscient, so I need people to\n> >communicate their intentions and decisions to me, and the best way to do that is\n> >with words.\n> >\n> >I should also point out that the GitHub UI is specifically designed to show the\n> >commit summary in the history view, so GitHub intends for you to write at least\n> >one line of helpful text (the summary) in this context.\n> >\n> >Overall, I don't believe your proposal is likely to gain traction here for the reasons I\n> >mentioned above, and I personally don't support it.\n> \n> The commit message is an essential part of why a change was made, in particular for forensics when something goes wrong, or when you are trying to figure out why you did something. Without a commit message, you are saying, \"yeah, ok, something happened.\" It's up there with reporting a bug saying, \"It doesn't work\", with no additional details - I have customers who do that, and it is not helpful. To be harsh about it, if someone commits something with no or a useless message, I will reject the change with impunity. Not explaining yourself is not helpful to those who come after. It's up there with \"Why did you not document your code, when you used single letter variables and strung the whole program on one line because C (or APL) allows it,\" with an answer along the lines of \"Any decent developer should be able to figure out the code.\" Sorry, but I feel very strongly on the subject that this is not a good idea. If you want to put junk in your commit, that is your business, but expect a\n>   significant segment of the population looking at your repo on GitHub to judge harshly. This sounds more like \"I don't want to use a version control system, but I have to for some reason, like HR metrics.\" I know I am being harsh on this, and I apologize in advance for it if I offended anyone, but I would want a way to disable (potentially at build time) this if it ever went forward.\n\nThere is nothing stopping you using '.' as the commit message which is\nas informative as when it is empty. Hence this enforcement of non-empty\ncommit message does not serve the stated purpose.\n\nSure, if you are merging someone's pull request you can enforce that the\nchanges are intelliginle by human review but that's not something git\ncan do automatically.\n\nAlso I have an auto-generated git repository of web pages in which every\nsingle commit message is the same. It is not empty because I was too\nlazy to figure out how to do that but the effective information value is\nthe same. And it's in git because the publication system uses git as\nbackend so there it goes.\n\nThanks\n\nMichal\n"},{"id":"453382","messageId":"CAPMMpoi50j7MzrsokQAcBWBgj8qGPN=j68PuEsppv629Oh7GHg@mail.gmail.com","threadId":"57693","inReplyTo":"20220409113244.GX163591@kunlun.suse.cz","subject":"Re: Make commit messages optional","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-04-10T13:59:33Z","receivedAt":"2022-04-10T13:59:51Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:\n>\n> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:\n> > On April 8, 2022 6:30 PM, brian m. carlson wrote:\n> > >On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n> > >> I think that often commit messages are unnecessary. I propose that by\n> > >> default a user should be able to commit without a message.\n[...]\n> > >We want to encourage good software engineering practices.\n> > >\n[...]\n> > >\n> > >Users who want this behaviour can use --allow-empty-message or create an alias\n> > >with that option.  The functionality already exists.  I use aliases extensively in my\n> > >development and I know others do as well, so this shouldn't be an impediment if\n> > >you're working on projects where this is acceptable.\n> > >\n[...]\n>\n> There is nothing stopping you using '.' as the commit message which is\n> as informative as when it is empty. Hence this enforcement of non-empty\n> commit message does not serve the stated purpose.\n\nMy apologies if this proposal has already been made in this or prior\ndiscussions - the list server and gmail are having another\ndisagreement, so I think I'm a few hours out of date.\n\nI believe the main argument *for* allowing empty commit messages by\ndefault is \"we shouldn't make it hard to do what you want to do, if\nyou can fix it later\", and the main argument *against* is \"for most\npeople (non-advanced users), what you do initially is what you end up\npushing, or at least trying to push, and fixing things later is *hard*\n- it requires a much deeper understanding of git than most people\notherwise necessarily need to develop\".\n\nIn that sense, allowing people to create empty commit messages when\nthey shouldn't, is often \"trapping\" them into a commit history that is\nless valuable (or even acceptable) than they might otherwise have\nachieved.\n\nWhile I therefore disagree with Aevar's proposal to \"allow empty, and\nadvise\", I do think the notion of giving advice makes perfect sense -\nlet's do it the other way around, with an advice message something\nlike:\n\n---\nEmpty commit messages aren't normally allowed, as they reduce the\nunderstandability of the commit history. If you do need to create a\ncommit with an empty message, you can do so by providing the\n'--allow-empty-message' argument to 'git commit'.\n---\n\nHas this already been considered/discussed? Would it meet the\nobjectives of those folks saying \"the rejection of empty messages\nwasted my time\", while also keeping the spirit of \"we should make it\neasy to do the right thing and harder to do the wrong thing,\nespecially for beginners\"?\n\nThanks,\nTao\n"},{"id":"453383","messageId":"013101d84ceb$afaa51b0$0efef510$@nexbridge.com","threadId":"57693","inReplyTo":"CAPMMpoi50j7MzrsokQAcBWBgj8qGPN=j68PuEsppv629Oh7GHg@mail.gmail.com","subject":"RE: Make commit messages optional","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-04-10T15:00:09Z","receivedAt":"2022-04-10T15:00:37Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 10, 2022 10:00 AM, Tao Klerks wrote:\n>To: Michal Suchánek <msuchanek@suse.de>\n>Cc: rsbecker@nexbridge.com; brian m. carlson <sandals@crustytoothpaste.net>;\n>jurgen_gjoncari@icloud.com; git@vger.kernel.org\n>Subject: Re: Make commit messages optional\n>\n>On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:\n>>\n>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:\n>> > On April 8, 2022 6:30 PM, brian m. carlson wrote:\n>> > >On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n>> > >> I think that often commit messages are unnecessary. I propose\n>> > >> that by default a user should be able to commit without a message.\n>[...]\n>> > >We want to encourage good software engineering practices.\n>> > >\n>[...]\n>> > >\n>> > >Users who want this behaviour can use --allow-empty-message or\n>> > >create an alias with that option.  The functionality already\n>> > >exists.  I use aliases extensively in my development and I know\n>> > >others do as well, so this shouldn't be an impediment if you're working on\n>projects where this is acceptable.\n>> > >\n>[...]\n>>\n>> There is nothing stopping you using '.' as the commit message which is\n>> as informative as when it is empty. Hence this enforcement of\n>> non-empty commit message does not serve the stated purpose.\n>\n>My apologies if this proposal has already been made in this or prior discussions -\n>the list server and gmail are having another disagreement, so I think I'm a few\n>hours out of date.\n>\n>I believe the main argument *for* allowing empty commit messages by default is\n>\"we shouldn't make it hard to do what you want to do, if you can fix it later\", and\n>the main argument *against* is \"for most people (non-advanced users), what you\n>do initially is what you end up pushing, or at least trying to push, and fixing things\n>later is *hard*\n>- it requires a much deeper understanding of git than most people otherwise\n>necessarily need to develop\".\n\nAdding commit messages has been part of SCM systems since virtually the beginning, at least on UNIX in the early 1970 and likely before. Adding a simple commit message is not onerous or difficult. \"Fixing it later\" will require the commit and any signature you put on at the time is lost. You also invalidate any signatures more recent in history. This does not corrupt your repo, but it does reduce its value. If you insist on doing this, use a single non-breaking space symbol in the -m option, which you can script or alias. Note that none of that will work on any git clients anyway. \n\nThe main argument against is that this violates the basic principles of a well managed DevSecOps environment that requires who, what, where, when, why for every change, not just the ones you publish. The key point here of having comments in commits is that it allows organizations to pull in projects like OpenSSL that ends up in production and must have the accountability for the installation to be allowed. Otherwise, just give up on the concept of Open-Source because corporate auditors will reject any request to use your project. You will never get into a PCI environment without a full set of commit comments, not just the Pull Requests.\n\nGranted my requirements come from regulated industries around the globe, and if you are making toys, so be it. My teams are making production-hardened applications.\n\n>In that sense, allowing people to create empty commit messages when they\n>shouldn't, is often \"trapping\" them into a commit history that is less valuable (or\n>even acceptable) than they might otherwise have achieved.\n>\n>While I therefore disagree with Aevar's proposal to \"allow empty, and advise\", I do\n>think the notion of giving advice makes perfect sense - let's do it the other way\n>around, with an advice message something\n>like:\n>\n>---\n>Empty commit messages aren't normally allowed, as they reduce the\n>understandability of the commit history. If you do need to create a commit with an\n>empty message, you can do so by providing the '--allow-empty-message'\n>argument to 'git commit'.\n>---\n>\n>Has this already been considered/discussed? Would it meet the objectives of\n>those folks saying \"the rejection of empty messages wasted my time\", while also\n>keeping the spirit of \"we should make it easy to do the right thing and harder to do\n>the wrong thing, especially for beginners\"?\n\nI am not personally going to be convinced of any of this - forgive me but, I think this reduces git's value and credibility as the leading SCM solution on the planet (and off) and see no justification for enabling comment-less repositories other than laziness. Even if that were the case, it is grounds for termination in my company and most of my customers to deliberately bypass audit practices, so if git moves forward with this, we might have to move elsewhere.\n--Randall\n\n"},{"id":"453384","messageId":"013201d84cee$3e8d88a0$bba899e0$@nexbridge.com","threadId":"57693","inReplyTo":"013101d84ceb$afaa51b0$0efef510$@nexbridge.com","subject":"RE: Make commit messages optional","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-04-10T15:18:28Z","receivedAt":"2022-04-10T15:18:59Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 10, 2022 11:00 AM, I wrote:\n>On April 10, 2022 10:00 AM, Tao Klerks wrote:\n>>To: Michal Suchánek <msuchanek@suse.de>\n>>Cc: rsbecker@nexbridge.com; brian m. carlson\n>><sandals@crustytoothpaste.net>; jurgen_gjoncari@icloud.com;\n>>git@vger.kernel.org\n>>Subject: Re: Make commit messages optional\n>>\n>>On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:\n>>>\n>>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:\n>>> > On April 8, 2022 6:30 PM, brian m. carlson wrote:\n>>> > >On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n>>> > >> I think that often commit messages are unnecessary. I propose\n>>> > >> that by default a user should be able to commit without a message.\n>>[...]\n>>> > >We want to encourage good software engineering practices.\n>>> > >\n>>[...]\n>>> > >\n>>> > >Users who want this behaviour can use --allow-empty-message or\n>>> > >create an alias with that option.  The functionality already\n>>> > >exists.  I use aliases extensively in my development and I know\n>>> > >others do as well, so this shouldn't be an impediment if you're\n>>> > >working on\n>>projects where this is acceptable.\n>>> > >\n>>[...]\n>>>\n>>> There is nothing stopping you using '.' as the commit message which\n>>> is as informative as when it is empty. Hence this enforcement of\n>>> non-empty commit message does not serve the stated purpose.\n>>\n>>My apologies if this proposal has already been made in this or prior\n>>discussions - the list server and gmail are having another\n>>disagreement, so I think I'm a few hours out of date.\n>>\n>>I believe the main argument *for* allowing empty commit messages by\n>>default is \"we shouldn't make it hard to do what you want to do, if you\n>>can fix it later\", and the main argument *against* is \"for most people\n>>(non-advanced users), what you do initially is what you end up pushing,\n>>or at least trying to push, and fixing things later is *hard*\n>>- it requires a much deeper understanding of git than most people\n>>otherwise necessarily need to develop\".\n>\n>Adding commit messages has been part of SCM systems since virtually the\n>beginning, at least on UNIX in the early 1970 and likely before. Adding a simple\n>commit message is not onerous or difficult. \"Fixing it later\" will require the commit\n>and any signature you put on at the time is lost. You also invalidate any signatures\n>more recent in history. This does not corrupt your repo, but it does reduce its\n>value. If you insist on doing this, use a single non-breaking space symbol in the -m\n>option, which you can script or alias. Note that none of that will work on any git\n>clients anyway.\n>\n>The main argument against is that this violates the basic principles of a well\n>managed DevSecOps environment that requires who, what, where, when, why\n>for every change, not just the ones you publish. The key point here of having\n>comments in commits is that it allows organizations to pull in projects like OpenSSL\n>that ends up in production and must have the accountability for the installation to\n>be allowed. Otherwise, just give up on the concept of Open-Source because\n>corporate auditors will reject any request to use your project. You will never get\n>into a PCI environment without a full set of commit comments, not just the Pull\n>Requests.\n>\n>Granted my requirements come from regulated industries around the globe, and\n>if you are making toys, so be it. My teams are making production-hardened\n>applications.\n>\n>>In that sense, allowing people to create empty commit messages when\n>>they shouldn't, is often \"trapping\" them into a commit history that is\n>>less valuable (or even acceptable) than they might otherwise have achieved.\n>>\n>>While I therefore disagree with Aevar's proposal to \"allow empty, and\n>>advise\", I do think the notion of giving advice makes perfect sense -\n>>let's do it the other way around, with an advice message something\n>>like:\n>>\n>>---\n>>Empty commit messages aren't normally allowed, as they reduce the\n>>understandability of the commit history. If you do need to create a\n>>commit with an empty message, you can do so by providing the '--allow-empty-\n>message'\n>>argument to 'git commit'.\n>>---\n>>\n>>Has this already been considered/discussed? Would it meet the\n>>objectives of those folks saying \"the rejection of empty messages\n>>wasted my time\", while also keeping the spirit of \"we should make it\n>>easy to do the right thing and harder to do the wrong thing, especially for\n>beginners\"?\n>\n>I am not personally going to be convinced of any of this - forgive me but, I think\n>this reduces git's value and credibility as the leading SCM solution on the planet\n>(and off) and see no justification for enabling comment-less repositories other\n>than laziness. Even if that were the case, it is grounds for termination in my\n>company and most of my customers to deliberately bypass audit practices, so if git\n>moves forward with this, we might have to move elsewhere.\n\nAnd I still don't get why the --allow-empty-message is not sufficient to meet your use case. git supports what is being requested already, not that it is allowed where I am. Are we talking about setting --allow-empty-message as the default? That is a major behavioural change. You could create a git command alias to always specify this option. So what is the point of this?\n\n"},{"id":"453386","messageId":"CAPMMpohnwTTwTEjr9u29O_qVJtQNuG29G3Ta+-rXz-De8zvMCQ@mail.gmail.com","threadId":"57693","inReplyTo":"013201d84cee$3e8d88a0$bba899e0$@nexbridge.com","subject":"Re: Make commit messages optional","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-04-10T16:27:30Z","receivedAt":"2022-04-10T16:27:46Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Sun, Apr 10, 2022 at 5:18 PM <rsbecker@nexbridge.com> wrote:\n> On April 10, 2022 11:00 AM, I wrote:\n> >On April 10, 2022 10:00 AM, Tao Klerks wrote:\n> >\n> >The main argument against is that this violates the basic principles of a well\n> >managed DevSecOps environment that requires who, what, where, when, why\n> >for every change, not just the ones you publish. The key point here of having\n> >comments in commits is that it allows organizations to pull in projects like OpenSSL\n> >that ends up in production and must have the accountability for the installation to\n> >be allowed. Otherwise, just give up on the concept of Open-Source because\n> >corporate auditors will reject any request to use your project. You will never get\n> >into a PCI environment without a full set of commit comments, not just the Pull\n> >Requests.\n\nI don't understand your point here. Allowing empty commit messages, as\nwell as near-empty commit messages, is already a part of the git\necosystem. Git itself does not, and could never, validate the\nvalue/meaningfulness of any commit messages. DevSecOps, corporate\ncompliance, accountability, auditability - these are all useful and\nnecessary concepts, but meeting their requirements is not the business\nof a client that millions of users use to do their daily work - it is\ninstead the business of secured server environments (that you might\nwant to push to), auditors, software supply chain management software,\netc.\n\nObviously your users (the ones that are expected to meet certain\nrequirements) should be discouraged or (more likely) prevented from\npushing messageless commits to the branches/environments that carry\nauditability requirements; I'm guessing they probably also need to\nhave references to other systems (eg ticketing systems) to provide an\nexternal \"rationale\" audit, GPG signature, ACLs and other things that\nare simply not the business of the client.\n\nI agree it would be a mistake to make it easier for such users (or any\nusers, really) to *accidentally* commit something without a message,\nand then find themselves in a not-always-obvious \"now I need to change\nthe past\" situation.\n\n> >\n> >Granted my requirements come from regulated industries around the globe, and\n> >if you are making toys, so be it. My teams are making production-hardened\n> >applications.\n\nNo amount of \"hardening\" the client that people run on their own\nmachines will improve the security of *your* applications in any way.\nAll the problems you describe involve *server* security. Whether other\npeople choose to use the client to make toys, or art, or banking\nsoftware, or git itself... is their business? The implication that the\nuse of git in \"serious industries\" should make it worse for other\nusers (such as toymakers) is, I believe, unhelpful at best.\n\n> >\n> >>In that sense, allowing people to create empty commit messages when\n> >>they shouldn't, is often \"trapping\" them into a commit history that is\n> >>less valuable (or even acceptable) than they might otherwise have achieved.\n> >>\n> >>While I therefore disagree with Aevar's proposal to \"allow empty, and\n> >>advise\", I do think the notion of giving advice makes perfect sense -\n> >>let's do it the other way around, with an advice message something\n> >>like:\n> >>\n> >>---\n> >>Empty commit messages aren't normally allowed, as they reduce the\n> >>understandability of the commit history. If you do need to create a\n> >>commit with an empty message, you can do so by providing the '--allow-empty-\n> >message'\n> >>argument to 'git commit'.\n> >>---\n> >>\n> >>Has this already been considered/discussed? Would it meet the\n> >>objectives of those folks saying \"the rejection of empty messages\n> >>wasted my time\", while also keeping the spirit of \"we should make it\n> >>easy to do the right thing and harder to do the wrong thing, especially for\n> >beginners\"?\n> >\n> >I am not personally going to be convinced of any of this - forgive me but, I think\n> >this reduces git's value and credibility as the leading SCM solution on the planet\n> >(and off) and see no justification for enabling comment-less repositories other\n> >than laziness. Even if that were the case, it is grounds for termination in my\n> >company and most of my customers to deliberately bypass audit practices, so if git\n> >moves forward with this, we might have to move elsewhere.\n\nGiven your earlier comments, I'm not sure I understand the \"this\"\nyou're not going to be convinced by or about. What I was proposing,\nand maybe I did a terrible job of it, is to *not* change the behavior\nof the client in any significant way, but rather add some new advice\n(which, like any git advice, can be turned off, eg by a corporate git\ninstaller), which would show alongside the current \"Aborting commit\ndue to empty commit message.\" error.\n\nThe exact text of that advice would obviously need to be carefully\nconsidered, but I would expect it to say something like \"committing\nwithout a message is typically a mistake (and might prevent you from\npushing to the server later), but if you really want or need to, you\ncan use the --allow-empty-message option\".\n\nThe point of this advice would be to clarify the existence of the\n\"--allow-empty-message\" behavior (and reduce the incidence of \"stupid\"\ncommit messages like single periods), *without* in any way increasing\nthe incidence of *accidental* submission without a commit message.\n\n>\n> And I still don't get why the --allow-empty-message is not sufficient to meet your use case. git supports what is being requested already, not that it is allowed where I am. Are we talking about setting --allow-empty-message as the default? That is a major behavioural change. You could create a git command alias to always specify this option. So what is the point of this?\n>\n\nMy proposal is that it absolutely is enough, functionally - but the\nabundance of \"we should change something\" concerns in this thread and\nelsewhere suggest, to me, that it might not be sufficiently\ndiscoverable; hence the \"advice\" proposal.\n"},{"id":"453390","messageId":"CANgJU+UPOOiDiErtht3T3GEhU+6HbkouZ4NUqPdk4o7X03kwpQ@mail.gmail.com","threadId":"57693","inReplyTo":"013101d84ceb$afaa51b0$0efef510$@nexbridge.com","subject":"Re: Make commit messages optional","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2022-04-11T09:04:36Z","receivedAt":"2022-04-11T09:04:54Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On Mon, 11 Apr 2022 at 09:27, <rsbecker@nexbridge.com> wrote:\n>\n> On April 10, 2022 10:00 AM, Tao Klerks wrote:\n> >To: Michal Suchánek <msuchanek@suse.de>\n> >Cc: rsbecker@nexbridge.com; brian m. carlson <sandals@crustytoothpaste.net>;\n> >jurgen_gjoncari@icloud.com; git@vger.kernel.org\n> >Subject: Re: Make commit messages optional\n> >\n> >On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:\n> >>\n> >> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:\n> >> > On April 8, 2022 6:30 PM, brian m. carlson wrote:\n> >> > >On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n> >> > >> I think that often commit messages are unnecessary. I propose\n> >> > >> that by default a user should be able to commit without a message.\n> >[...]\n> >> > >We want to encourage good software engineering practices.\n> >> > >\n> >[...]\n> >> > >\n> >> > >Users who want this behaviour can use --allow-empty-message or\n> >> > >create an alias with that option.  The functionality already\n> >> > >exists.  I use aliases extensively in my development and I know\n> >> > >others do as well, so this shouldn't be an impediment if you're working on\n> >projects where this is acceptable.\n> >> > >\n> >[...]\n> >>\n> >> There is nothing stopping you using '.' as the commit message which is\n> >> as informative as when it is empty. Hence this enforcement of\n> >> non-empty commit message does not serve the stated purpose.\n> >\n> >My apologies if this proposal has already been made in this or prior discussions -\n> >the list server and gmail are having another disagreement, so I think I'm a few\n> >hours out of date.\n> >\n> >I believe the main argument *for* allowing empty commit messages by default is\n> >\"we shouldn't make it hard to do what you want to do, if you can fix it later\", and\n> >the main argument *against* is \"for most people (non-advanced users), what you\n> >do initially is what you end up pushing, or at least trying to push, and fixing things\n> >later is *hard*\n> >- it requires a much deeper understanding of git than most people otherwise\n> >necessarily need to develop\".\n>\n> Adding commit messages has been part of SCM systems since virtually the beginning, at least on UNIX in the early 1970 and likely before. Adding a simple commit message is not onerous or difficult. \"Fixing it later\" will require the commit and any signature you put on at the time is lost. You also invalidate any signatures more recent in history. This does not corrupt your repo, but it does reduce its value. If you insist on doing this, use a single non-breaking space symbol in the -m option, which you can script or alias. Note that none of that will work on any git clients anyway.\n>\n> The main argument against is that this violates the basic principles of a well managed DevSecOps environment that requires who, what, where, when, why for every change, not just the ones you publish. The key point here of having comments in commits is that it allows organizations to pull in projects like OpenSSL that ends up in production and must have the accountability for the installation to be allowed. Otherwise, just give up on the concept of Open-Source because corporate auditors will reject any request to use your project. You will never get into a PCI environment without a full set of commit comments, not just the Pull Requests.\n>\n> Granted my requirements come from regulated industries around the globe, and if you are making toys, so be it. My teams are making production-hardened applications.\n\nFirst off, git already allows empty commit messages. If you aren't\nalready validating the commits that are being pushed to your central\nrepo then you are already allowing commits with no commit message.\nHave your auditors noticed or complained?\n\nSecond, I think you really did not understand Avar's point. Let me try\nto restate it in simple terms.\n\nOne of the things that separates git from most other SCM's, especially\nlegacy SCM's, is that it separates the act of creating a commit and\nthat of pushing it to the upstream repo.\n\nAdvanced git users make very heavy use of git rebase --interactive and\nsimilar tools to modify, reorder, reword, merge, split, and otherwise\nmunge the commits they have created *locally* before they push them\nupstream.\n\nWhat Avar is saying is that there really is no reason to require a\ncommit message *locally* when a user is likely to be doing such\nactivities. Instead what should happen is that the upstream should be\ntaught to refuse commits pushed to it which do not comply with\nwhatever audit rules you wish to enforce.\n\nFor instance, your audit rules could require that every commit\nincludes verbiage like \"I understand that I am responsible for the\ncontent of this commit, I understand the rules which this commit must\ncomply with, and that I will be held accountable for any deviations\nfrom those rules.\"  Would there be any point in enforcing this locally\non commits which are intended to be thrown away and squashed before\nthey are sent? I would say no, for a bunch of reasons, not least being\nthat preventative controls cannot be relied on in an uncontrolled\nenvironment like someone's laptop, and if you weren't *also*\nvalidating those rules upstream then your protections would be as\nsecure as using client side JS to validate entry to a web-form - that\nis not secure *at all*.\n\nThe only way to be really sure that no commits end up in your master\nrepository that do not comply with your rules is to validate the rules\non push to the master repository, and to reject any attempt to push\ncommits which do not comply.\n\nI often create dozens of tiny commits with the words \"WIP\" (work in\nprogress), which I then later reorder, and then squash together into a\nnice logical and well explained series of commits, at which time I\ngive them nice detailed commit messages. Requiring me to type 'WIP\"\nevery time is really unnecessary and not particularly helpful to\nanyone. I dont use --allow-empty-mesage because -m'WIP' is less to\ntype than --allow-empty-message, but that is besides the point 'WIP'\nis not an acceptable commit message to an auditor and should not be\nmerged.\n\n> >In that sense, allowing people to create empty commit messages when they\n> >shouldn't, is often \"trapping\" them into a commit history that is less valuable (or\n> >even acceptable) than they might otherwise have achieved.\n> >\n> >While I therefore disagree with Aevar's proposal to \"allow empty, and advise\", I do\n> >think the notion of giving advice makes perfect sense - let's do it the other way\n> >around, with an advice message something\n> >like:\n> >\n> >---\n> >Empty commit messages aren't normally allowed, as they reduce the\n> >understandability of the commit history. If you do need to create a commit with an\n> >empty message, you can do so by providing the '--allow-empty-message'\n> >argument to 'git commit'.\n> >---\n> >\n> >Has this already been considered/discussed? Would it meet the objectives of\n> >those folks saying \"the rejection of empty messages wasted my time\", while also\n> >keeping the spirit of \"we should make it easy to do the right thing and harder to do\n> >the wrong thing, especially for beginners\"?\n>\n\n> I am not personally going to be convinced of any of this - forgive me but, I think this reduces git's value and credibility as the leading SCM solution on the planet (and off) and see no justification for enabling comment-less repositories other than laziness. Even if that were the case, it is grounds for termination in my company and most of my customers to deliberately bypass audit practices, so if git moves forward with this, we might have to move elsewhere.\n\nWith respect I dont think you actually understand how the audit\nprocess works; a developers laptop is not a controlled environment\nwhich is trustable by an auditor.  As has already been stated by\nseveral posters git *already* allows empty commits messages, and if\nyou are not implementing controls in your master repository that all\npushed commits to controlled branches comply with your rules then you\n*already* have a vector to allow such commits into your master\nrepository and you are probably not in compliance with your auditors\nrequirements.\n\nPreventive controls can *only* be effective and relied on when\nexecuted inside of a completely controlled context. A dev's local\nworking context is NOT a completely controlled context. Think about\nit, they have a compiler on hand, they can do anything their skills\nallow them to do. Even if git did not *already* allow empty messages a\nsuitably skilled dev could always hack git to allow them. If you did\nnot have preventive controls upstream at the master repo you are using\nfor audit controls then whatever policy might be baked into the\ncurrent git client is moot. Someone could hand roll a commit that\nviolated them and send them using something other than git. This is\nall just software after all.\n\nIf you are concerned about the audit practices that your company needs\nto comply with then you should be looking at server-side hooks\n(pre-receive hooks) in your master repository, not client side rules\nin the git executable your devs use, those rules are ineffective and\nultimately should be deemed unreliable by any competent auditor.\n\nNote that most auditors do *not* require every control to be\npreventive, they strongly prefer preventive controls for obvious\nreasons, but they also understand that not every rule can be\nimplemented as a preventive control, so they also allow *detective*\ncontrols, eg, a daily report showing that all commits in the master\nrepo comply with their requirements. You may be able to work with your\nauditor to implement detective controls instead. However, given that\ngit absolutely does have the ability to implement upstream preventive\ncontrols it seems that you should focus your concerns there.\n\nBTW, I am saying this as someone who has had extensive experience\nworking with auditors on git controls for many years. Nothing you do\nclient side is relevant to the auditor and if it is you should hire a\nnew auditor yours is not competent. If you dont verify things in a\ncontrolled environment then you haven't controlled things at all.\n\nConsider if one of your devs writes a commit with an empty message and\nthat commit is never pushed upstream have they broken a rule? I bet\nnot. Consider a common audit policy of requiring \"two head approval\",\neg two people need to approve that a commit is reasonable to be\nmerged. In corporate context most auditors will consider the author of\nthe commit to be one, head, but usually some upstream tool, say github\nor gitlab, is responsible for managing the approval process for the\nsecond head. Since every commit created locally cannot have two\napprovers at its time of creation this means that every commit is\ncreated in violation of the audit rules.  But auditors don't have any\nconcern with this because they know that the real concern is ensuring\na robust controls process is applied before that commit can be pushed\nupstream and merged into the central repository.\n\nSo with respect, I think you really don't understand how the audit\nprocess works and you really haven't thought through your concern.\nWhatever happens locally on the developers box is immaterial to the\nauditor, they only care about the upstream master repo. Heck they\nmight not even care about that and only care about the commits that\nare actually compiled or deployed to a production environment. So you\ncould have your preventive controls in the build stage and not in the\nSCM at all. But most companies would prefer to implement such controls\nrelatively close to the person/subject being controlled and would\nprefer to see proper well implemented and strong preventive controls\nin your master repo's pre-receive hooks.\n\nIn my former job we used a combination of preventive and detective\ncontrols. It is a web shop where a deployment could happen at any\ntime, and some controls can interfere with outage resolution and\nfire-fighting, so we had a magic phrase that could be used to bypass\nthe preventive controls but would trigger a detective control to\nreview what happened and ensure that it was all above board. I was one\nof the people who would have to review the use of the bypass. No\nauditor had any issue with this. Auditors are usually pretty\nreasonable people.\n\ncheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"453397","messageId":"220411.865ynfkj7r.gmgdl@evledraar.gmail.com","threadId":"57693","inReplyTo":"CA+JQ7M-uSatD4=HHxaqe4yVAJ5WGuWC_BprX4hnfKSrt6-1GEg@mail.gmail.com","subject":"Re: Make commit messages optional","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-11T10:24:41Z","receivedAt":"2022-04-11T10:28:37Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 08 2022, Erik Cervin Edin wrote:\n\n> At the risk of bikeshedding.\n>\n> The case in favor of not allowing empty commit messages by default is\n> that most of the time, empty commit messages are useless.\n>\n> I've written my fair share of poor commit messages (-,..., wip, foo).\n> Sometimes I've fixed that retroactively, sometimes not. The advantage\n> I see with empty commit messages is that it's more ubiquitous to\n> \"write something better\" or \"whatever\". The downside is I can't git\n> log --grep '^$' to find them.\n\nYou can:\n\n    git log --invert-grep --grep '.'\n\n> On Fri, Apr 8, 2022 at 7:47 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>> E.g. I wouldn't mind if we made pushes start failing (probably guarded\n>> by appropriate isatty() checks) if the user was pushing content without\n>> commit messages, unless some option were overridden, or we could start\n>> sternly warning about that. Ditto for merging a branch into another one\n>> (especially if we can see it's the default branch).\n>\n> I could see this being a potentially nice option but also pretty much\n> .git/hooks/pre-push.sample but with rev-list --grep '^$'  (which\n> doesn't appear to work)\n\nThe reason it doesn't work is that our --grep doesn't allow for matching\nacross the whole message, we should fix that, it would be useful in\nother contexts.\n\nBut for this the --invert-grep above will do what you want. I.e. if our\n--grep matches any one character and we discard any that matched with\n--invert-grep we're left with empty commit messages.\n"},{"id":"453398","messageId":"220411.861qy3khkk.gmgdl@evledraar.gmail.com","threadId":"57693","inReplyTo":"CAPMMpoi50j7MzrsokQAcBWBgj8qGPN=j68PuEsppv629Oh7GHg@mail.gmail.com","subject":"Re: Make commit messages optional","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-11T10:19:51Z","receivedAt":"2022-04-11T11:03:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Apr 10 2022, Tao Klerks wrote:\n\n> On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:\n>>\n>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:\n>> > On April 8, 2022 6:30 PM, brian m. carlson wrote:\n>> > >On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n>> > >> I think that often commit messages are unnecessary. I propose that by\n>> > >> default a user should be able to commit without a message.\n> [...]\n>> > >We want to encourage good software engineering practices.\n>> > >\n> [...]\n>> > >\n>> > >Users who want this behaviour can use --allow-empty-message or create an alias\n>> > >with that option.  The functionality already exists.  I use aliases extensively in my\n>> > >development and I know others do as well, so this shouldn't be an impediment if\n>> > >you're working on projects where this is acceptable.\n>> > >\n> [...]\n>>\n>> There is nothing stopping you using '.' as the commit message which is\n>> as informative as when it is empty. Hence this enforcement of non-empty\n>> commit message does not serve the stated purpose.\n>\n> My apologies if this proposal has already been made in this or prior\n> discussions - the list server and gmail are having another\n> disagreement, so I think I'm a few hours out of date.\n>\n> I believe the main argument *for* allowing empty commit messages by\n> default is \"we shouldn't make it hard to do what you want to do, if\n> you can fix it later\",\n\nOr don't fix it later, e.g. in the gist case mentioned in [1]. As shown\nin [2] forcing the user to provide a message can serve to increase the\nnoise to signal ratio, in making it harder to distinguish those commits\nwhere the author had nothing to say.\n\nI have numerous local repos where I'd benefit from --allow-empty-message\nby default (of course I can customize it, but habits etc). Now through\nsome combination of scripting and habits I've ended up with e.g.:\n\n    git commit -mbump\n\nThese are things like my local (private) notes file, a repo that keeps\nsnapshots of E-Mails I send to the Git ML etc. Those things are newer\ngoing to have meaningful commit messages.\n\n> and the main argument *against* is \"for most\n> people (non-advanced users), what you do initially is what you end up\n> pushing, or at least trying to push, and fixing things later is *hard*\n> - it requires a much deeper understanding of git than most people\n> otherwise necessarily need to develop\".\n\nYes, maybe it won't be viable to go in that direction, but re this in my\n[1]:\n\t\n\tBut I'm also pretty sure that those people are engaged in a proxy war,\n\tand we should just attack the \"problem\" directly instead. I.e. it's not\n\ta problem that some commit somewhere has an empty message, rather it's\n\tthat such a commit gets \"propagated\". A better place to check for it is\n\tthen at the point of point of propagation.\n\nI think it would be useful if those advocating for this behavior would\nindicate whether or not some working solution of doing it in a different\nplace would address their concerns, whether or not we have patches ready\nfor that.\n\nE.g. something that (if you have empty commit messages) would prompt you\nto interactively rebase the to-be-pushed history or whatever.\n\nAnother thing that occurred to me after sending [1] was that perhaps\n\"repo size\" would be good heuristic, we already have a fast estimation\nof that for showing abbreviated commit OIDs.\n\nThat wouldn't do the right thing on e.g. large private git-annex repos,\nbut would serve to distinguish a \"real, mid-size or large repo\" like\ngit.git, redis.git, linux.git etc. from dotfiles, gists etc.\n\t\n> In that sense, allowing people to create empty commit messages when\n> they shouldn't, is often \"trapping\" them into a commit history that is\n> less valuable (or even acceptable) than they might otherwise have\n> achieved.\n\nI agree with that if you s/allowing people to create empty/force people\nto create non-empty/ :)\n\nI think all the arguments in this thread (including mine) are ultimately\nbuilt on anecdotes, and I don't think that we can hope to get out of\nthat rut.\n\nE.g. I've helped a lot of novice people with git (being the go-to \"git\nguy\" at a past job), and one of *the most common* things I encountered\nwas users with some absolute mess of a working tree with large\noutstanding changes, which ultimately came down to them being afraid to\ncommit it as it \"wasn't ready\".\n\nSo I really think anything we can do to break that particular pattern is\nmore helpful than not.\n\nBut am I absolutely confident that I'm right, and that these concerns\nwill outweigh other anecdotes brought up in this thread? No.\n\nBut what I am confident in saying is that tweaking the UX in this area\nwill have cost/benefits whatever you do, and I think that whatever\n\"side\" one picks here the interesting arguments to be had is trying to\ndiscuss and mitigate those costs.\n\n> While I therefore disagree with Aevar's proposal to \"allow empty, and\n> advise\", I do think the notion of giving advice makes perfect sense -\n> let's do it the other way around, with an advice message something\n> like:\n\nNote that that's a pretty narrow reading of [1]. The main thrust of my\npoint was that we should consider moving this to \"push\" or \"merge\" time.\n\n> ---\n> Empty commit messages aren't normally allowed, as they reduce the\n> understandability of the commit history. If you do need to create a\n> commit with an empty message, you can do so by providing the\n> '--allow-empty-message' argument to 'git commit'.\n> ---\n> Has this already been considered/discussed? Would it meet the\n> objectives of those folks saying \"the rejection of empty messages\n> wasted my time\", while also keeping the spirit of \"we should make it\n> easy to do the right thing and harder to do the wrong thing,\n> especially for beginners\"?\n\nI think that's a lot worse than the status quo, at least now our\nbehavior just seems like a very basic safeguard, e.g.:\n\t\n\t$ git commit -a\n\thint: Waiting for your editor to close the file... Waiting for Emacs...\n\tAborting commit due to empty commit message.\n\nThere I opened my editor, saved the empty file that came up (\"empty\"\nwhen adjusted for comments), and \"git commit\" aborted.\n\nEven if I think we should make some version of \"allow empty\" the default\nI think *that* particular thing should stay.\n\nI.e. that's really helping a user to mitigate a genuine mistake,\nparticularly if something goes wrong with the external editor. I.e. I\nthink something like this would be sufficient (as in, it should\nsucceed):\n\n    $ git commit -a --no-edit\n    Aborting commit due to empty commit message.\n\nAll of those would be good cases to get feedback on, i.e. let's leave\naside the question of whether the UX should \"encourage\" and whether\n--allow-empty-message should be the default, do the proponents of the\nstatus quo think all of these are sensible:\n\n    git commit -a # launches editor\n    git commit -a -m\"\" # empty message\n    git commit -a --no-edit # no editor\n\nAside from anything else I think --allow-empty-message for that last one\nis rather silly, it's basically making the user say\n--yes-i-know-the-default-messages-is-the-empty-message. Maybe it's\narguably in the case of a pre-commit hook & without --no-verify?\n\nAnyway, that was a bit of a digression, sorry.\n\nThe reason I think it's \"worse than the status quo\" is that it takes us\nfrom something that seems to be an overzelous CLI option check gone\nwrong to actively recommending a \"novice forever\" UX pattern. I.e. the\n\"reduce the understandability of the commit history\" etc. assumes or\nimplies that we won't have a \"git rebase -i\" before pushing.\n\n1. https://lore.kernel.org/git/220408.86r167bxra.gmgdl@evledraar.gmail.com/\n2. https://lore.kernel.org/git/220411.865ynfkj7r.gmgdl@evledraar.gmail.com/\n"},{"id":"453402","messageId":"016701d84d98$350000b0$9f000210$@nexbridge.com","threadId":"57693","inReplyTo":"CANgJU+UPOOiDiErtht3T3GEhU+6HbkouZ4NUqPdk4o7X03kwpQ@mail.gmail.com","subject":"RE: Make commit messages optional","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-04-11T11:35:06Z","receivedAt":"2022-04-11T11:35:52Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 11, 2022 5:05 AM, demerphq wrote:\n>On Mon, 11 Apr 2022 at 09:27, <rsbecker@nexbridge.com> wrote:\n>>\n>> On April 10, 2022 10:00 AM, Tao Klerks wrote:\n>> >To: Michal Suchánek <msuchanek@suse.de>\n>> >Cc: rsbecker@nexbridge.com; brian m. carlson\n>> ><sandals@crustytoothpaste.net>; jurgen_gjoncari@icloud.com;\n>> >git@vger.kernel.org\n>> >Subject: Re: Make commit messages optional\n>> >\n>> >On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:\n>> >>\n>> >> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:\n>> >> > On April 8, 2022 6:30 PM, brian m. carlson wrote:\n>> >> > >On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:\n>> >> > >> I think that often commit messages are unnecessary. I propose\n>> >> > >> that by default a user should be able to commit without a message.\n>> >[...]\n>> >> > >We want to encourage good software engineering practices.\n>> >> > >\n>> >[...]\n>> >> > >\n>> >> > >Users who want this behaviour can use --allow-empty-message or\n>> >> > >create an alias with that option.  The functionality already\n>> >> > >exists.  I use aliases extensively in my development and I know\n>> >> > >others do as well, so this shouldn't be an impediment if you're\n>> >> > >working on\n>> >projects where this is acceptable.\n>> >> > >\n>> >[...]\n>> >>\n>> >> There is nothing stopping you using '.' as the commit message which\n>> >> is as informative as when it is empty. Hence this enforcement of\n>> >> non-empty commit message does not serve the stated purpose.\n>> >\n>> >My apologies if this proposal has already been made in this or prior\n>> >discussions - the list server and gmail are having another\n>> >disagreement, so I think I'm a few hours out of date.\n>> >\n>> >I believe the main argument *for* allowing empty commit messages by\n>> >default is \"we shouldn't make it hard to do what you want to do, if\n>> >you can fix it later\", and the main argument *against* is \"for most\n>> >people (non-advanced users), what you do initially is what you end up\n>> >pushing, or at least trying to push, and fixing things later is\n>> >*hard*\n>> >- it requires a much deeper understanding of git than most people\n>> >otherwise necessarily need to develop\".\n>>\n>> Adding commit messages has been part of SCM systems since virtually the\n>beginning, at least on UNIX in the early 1970 and likely before. Adding a simple\n>commit message is not onerous or difficult. \"Fixing it later\" will require the commit\n>and any signature you put on at the time is lost. You also invalidate any signatures\n>more recent in history. This does not corrupt your repo, but it does reduce its\n>value. If you insist on doing this, use a single non-breaking space symbol in the -m\n>option, which you can script or alias. Note that none of that will work on any git\n>clients anyway.\n>>\n>> The main argument against is that this violates the basic principles of a well\n>managed DevSecOps environment that requires who, what, where, when, why\n>for every change, not just the ones you publish. The key point here of having\n>comments in commits is that it allows organizations to pull in projects like OpenSSL\n>that ends up in production and must have the accountability for the installation to\n>be allowed. Otherwise, just give up on the concept of Open-Source because\n>corporate auditors will reject any request to use your project. You will never get\n>into a PCI environment without a full set of commit comments, not just the Pull\n>Requests.\n>>\n>> Granted my requirements come from regulated industries around the globe,\n>and if you are making toys, so be it. My teams are making production-hardened\n>applications.\n>\n>First off, git already allows empty commit messages. If you aren't already\n>validating the commits that are being pushed to your central repo then you are\n>already allowing commits with no commit message.\n>Have your auditors noticed or complained?\n>\n>Second, I think you really did not understand Avar's point. Let me try to restate it\n>in simple terms.\n>\n>One of the things that separates git from most other SCM's, especially legacy\n>SCM's, is that it separates the act of creating a commit and that of pushing it to the\n>upstream repo.\n>\n>Advanced git users make very heavy use of git rebase --interactive and similar\n>tools to modify, reorder, reword, merge, split, and otherwise munge the commits\n>they have created *locally* before they push them upstream.\n>\n>What Avar is saying is that there really is no reason to require a commit message\n>*locally* when a user is likely to be doing such activities. Instead what should\n>happen is that the upstream should be taught to refuse commits pushed to it\n>which do not comply with whatever audit rules you wish to enforce.\n>\n>For instance, your audit rules could require that every commit includes verbiage\n>like \"I understand that I am responsible for the content of this commit, I\n>understand the rules which this commit must comply with, and that I will be held\n>accountable for any deviations from those rules.\"  Would there be any point in\n>enforcing this locally on commits which are intended to be thrown away and\n>squashed before they are sent? I would say no, for a bunch of reasons, not least\n>being that preventative controls cannot be relied on in an uncontrolled\n>environment like someone's laptop, and if you weren't *also* validating those\n>rules upstream then your protections would be as secure as using client side JS to\n>validate entry to a web-form - that is not secure *at all*.\n>\n>The only way to be really sure that no commits end up in your master repository\n>that do not comply with your rules is to validate the rules on push to the master\n>repository, and to reject any attempt to push commits which do not comply.\n>\n>I often create dozens of tiny commits with the words \"WIP\" (work in progress),\n>which I then later reorder, and then squash together into a nice logical and well\n>explained series of commits, at which time I give them nice detailed commit\n>messages. Requiring me to type 'WIP\"\n>every time is really unnecessary and not particularly helpful to anyone. I dont use -\n>-allow-empty-mesage because -m'WIP' is less to type than --allow-empty-\n>message, but that is besides the point 'WIP'\n>is not an acceptable commit message to an auditor and should not be merged.\n>\n>> >In that sense, allowing people to create empty commit messages when\n>> >they shouldn't, is often \"trapping\" them into a commit history that\n>> >is less valuable (or even acceptable) than they might otherwise have achieved.\n>> >\n>> >While I therefore disagree with Aevar's proposal to \"allow empty, and\n>> >advise\", I do think the notion of giving advice makes perfect sense -\n>> >let's do it the other way around, with an advice message something\n>> >like:\n>> >\n>> >---\n>> >Empty commit messages aren't normally allowed, as they reduce the\n>> >understandability of the commit history. If you do need to create a\n>> >commit with an empty message, you can do so by providing the '--allow-\n>empty-message'\n>> >argument to 'git commit'.\n>> >---\n>> >\n>> >Has this already been considered/discussed? Would it meet the\n>> >objectives of those folks saying \"the rejection of empty messages\n>> >wasted my time\", while also keeping the spirit of \"we should make it\n>> >easy to do the right thing and harder to do the wrong thing, especially for\n>beginners\"?\n>>\n>\n>> I am not personally going to be convinced of any of this - forgive me but, I think\n>this reduces git's value and credibility as the leading SCM solution on the planet\n>(and off) and see no justification for enabling comment-less repositories other\n>than laziness. Even if that were the case, it is grounds for termination in my\n>company and most of my customers to deliberately bypass audit practices, so if git\n>moves forward with this, we might have to move elsewhere.\n>\n>With respect I dont think you actually understand how the audit process works; a\n>developers laptop is not a controlled environment which is trustable by an auditor.\n>As has already been stated by several posters git *already* allows empty commits\n>messages, and if you are not implementing controls in your master repository that\n>all pushed commits to controlled branches comply with your rules then you\n>*already* have a vector to allow such commits into your master repository and\n>you are probably not in compliance with your auditors requirements.\n>\n>Preventive controls can *only* be effective and relied on when executed inside of\n>a completely controlled context. A dev's local working context is NOT a completely\n>controlled context. Think about it, they have a compiler on hand, they can do\n>anything their skills allow them to do. Even if git did not *already* allow empty\n>messages a suitably skilled dev could always hack git to allow them. If you did not\n>have preventive controls upstream at the master repo you are using for audit\n>controls then whatever policy might be baked into the current git client is moot.\n>Someone could hand roll a commit that violated them and send them using\n>something other than git. This is all just software after all.\n>\n>If you are concerned about the audit practices that your company needs to comply\n>with then you should be looking at server-side hooks (pre-receive hooks) in your\n>master repository, not client side rules in the git executable your devs use, those\n>rules are ineffective and ultimately should be deemed unreliable by any\n>competent auditor.\n>\n>Note that most auditors do *not* require every control to be preventive, they\n>strongly prefer preventive controls for obvious reasons, but they also understand\n>that not every rule can be implemented as a preventive control, so they also allow\n>*detective* controls, eg, a daily report showing that all commits in the master\n>repo comply with their requirements. You may be able to work with your auditor\n>to implement detective controls instead. However, given that git absolutely does\n>have the ability to implement upstream preventive controls it seems that you\n>should focus your concerns there.\n>\n>BTW, I am saying this as someone who has had extensive experience working with\n>auditors on git controls for many years. Nothing you do client side is relevant to\n>the auditor and if it is you should hire a new auditor yours is not competent. If you\n>dont verify things in a controlled environment then you haven't controlled things\n>at all.\n>\n>Consider if one of your devs writes a commit with an empty message and that\n>commit is never pushed upstream have they broken a rule? I bet not. Consider a\n>common audit policy of requiring \"two head approval\", eg two people need to\n>approve that a commit is reasonable to be merged. In corporate context most\n>auditors will consider the author of the commit to be one, head, but usually some\n>upstream tool, say github or gitlab, is responsible for managing the approval\n>process for the second head. Since every commit created locally cannot have two\n>approvers at its time of creation this means that every commit is created in\n>violation of the audit rules.  But auditors don't have any concern with this because\n>they know that the real concern is ensuring a robust controls process is applied\n>before that commit can be pushed upstream and merged into the central\n>repository.\n>\n>So with respect, I think you really don't understand how the audit process works\n>and you really haven't thought through your concern.\n>Whatever happens locally on the developers box is immaterial to the auditor, they\n>only care about the upstream master repo. Heck they might not even care about\n>that and only care about the commits that are actually compiled or deployed to a\n>production environment. So you could have your preventive controls in the build\n>stage and not in the SCM at all. But most companies would prefer to implement\n>such controls relatively close to the person/subject being controlled and would\n>prefer to see proper well implemented and strong preventive controls in your\n>master repo's pre-receive hooks.\n\nI am going to bow out of this conversion since it has become personal and attacks my credibility in a manner that is offensive. You are obviously entitled to have your opinion but I would appreciate if you would keep this on the facts and use cases instead of saying of going with an ad hominem approach to the discussion that I do not understand this or that so my argument must be wrong. My experience is my own and you do not know me or what I do or with whom I work. Thank you for your critique.\n--Randall\n\n"},{"id":"453404","messageId":"CAPMMpohNYizpbqerAuFZnSY9mFsTJEJbfFWNGY41GcHxdwGrew@mail.gmail.com","threadId":"57693","inReplyTo":"220411.861qy3khkk.gmgdl@evledraar.gmail.com","subject":"Re: Make commit messages optional","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-04-11T12:39:12Z","receivedAt":"2022-04-11T12:39:36Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Mon, Apr 11, 2022 at 1:03 PM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n>\n> E.g. something that (if you have empty commit messages) would prompt you\n> to interactively rebase the to-be-pushed history or whatever.\n\nPersonally, I strive to recommend workflows where rebasing is not\nnecessary, and I believe that this is a better direction for git to go\nin, rather than rebasing-by-default.\n\nRebasing is awesome, I use it all the time, it is definitely part of\nthe joy (my joy?) of using git - but again, the more we can design\nworkflows where rebasing is a private matter, the better the on-ramp\nlooks, I believe.\n\n>\n> Another thing that occurred to me after sending [1] was that perhaps\n> \"repo size\" would be good heuristic, we already have a fast estimation\n> of that for showing abbreviated commit OIDs.\n>\n> That wouldn't do the right thing on e.g. large private git-annex repos,\n> but would serve to distinguish a \"real, mid-size or large repo\" like\n> git.git, redis.git, linux.git etc. from dotfiles, gists etc.\n\nI'm sorry, I didn't get it; are you proposing that empty commit\nmessages should be more acceptable in small repos, presumably on the\nassumption that they are likely private?\n\n>\n> > In that sense, allowing people to create empty commit messages when\n> > they shouldn't, is often \"trapping\" them into a commit history that is\n> > less valuable (or even acceptable) than they might otherwise have\n> > achieved.\n>\n> I agree with that if you s/allowing people to create empty/force people\n> to create non-empty/ :)\n\nAt the risk of projecting my own experience too much, I'd like to\nunderstand the assumptions in play: I assume that most people\ncommitting in git end up doing so in the context of some process, some\norganization, with the goal of eventually pushing the work \"upstream\",\nto somewhere others will be able to evaluate and/or benefit from the\nchange. I assume that people using git as part of personal logging\nsystems, backup systems etc is far more rare, and that the mindset\nassociated with committing to most single-user private projects is\nstill \"one day, I'll want to make use of that\".\n\nGiven these assumptions, I personally believe that the cost to a new\nuser of having to figure out how to change a commit message (and not\nfall afoul of the many risks changing the past introduces, eg\naccidentally duplicating history via a \"merge pull\" after a rebase of\nalready-pushed commits), is higher than the risk of a user being\nintimidated by the need to write a message and choosing to not write\n(or commit) anything, rather than writing something silly.\n\nAll that said, I'll happily bow to the experience of my betters, of\nwhich there are many already in this thread. My objective in joining\nthe discussion was only to point out that enhancing the\n*discoverability* (of the empty-commit-message option) may allay\n*some* of the sentiment behind this thread's initiation and popularity\nwithout aggravating the counter-concerns raised.\n\n\n>\n> E.g. I've helped a lot of novice people with git (being the go-to \"git\n> guy\" at a past job), and one of *the most common* things I encountered\n> was users with some absolute mess of a working tree with large\n> outstanding changes, which ultimately came down to them being afraid to\n> commit it as it \"wasn't ready\".\n>\n> So I really think anything we can do to break that particular pattern is\n> more helpful than not.\n\nI can see how such a tendency may be aggravated by the need to set a\nmessage, but I still don't believe the risk/reward of *more often\naccidentally* creating commits without commit messages would be\nfavorable.\n\n> But what I am confident in saying is that tweaking the UX in this area\n> will have cost/benefits whatever you do, and I think that whatever\n> \"side\" one picks here the interesting arguments to be had is trying to\n> discuss and mitigate those costs.\n>\n\n+1\n\n> > While I therefore disagree with Aevar's proposal to \"allow empty, and\n> > advise\", I do think the notion of giving advice makes perfect sense -\n> > let's do it the other way around, with an advice message something\n> > like:\n>\n> Note that that's a pretty narrow reading of [1]. The main thrust of my\n> point was that we should consider moving this to \"push\" or \"merge\" time.\n\nMy apologies for the misunderstanding and misrepresentation; as far as\nI can tell I disagree with you on the desirability of push/merge-time\ncommit modification automation or advice, but I clearly did not\nread/understand your proposal properly before paraphrasing it.\n\n>\n> > ---\n> > Empty commit messages aren't normally allowed, as they reduce the\n> > understandability of the commit history. If you do need to create a\n> > commit with an empty message, you can do so by providing the\n> > '--allow-empty-message' argument to 'git commit'.\n> > ---\n> > Has this already been considered/discussed? Would it meet the\n> > objectives of those folks saying \"the rejection of empty messages\n> > wasted my time\", while also keeping the spirit of \"we should make it\n> > easy to do the right thing and harder to do the wrong thing,\n> > especially for beginners\"?\n>\n> I think that's a lot worse than the status quo, at least now our\n> behavior just seems like a very basic safeguard, e.g.:\n>\n>         $ git commit -a\n>         hint: Waiting for your editor to close the file... Waiting for Emacs...\n>         Aborting commit due to empty commit message.\n>\n> There I opened my editor, saved the empty file that came up (\"empty\"\n> when adjusted for comments), and \"git commit\" aborted.\n>\n> Even if I think we should make some version of \"allow empty\" the default\n> I think *that* particular thing should stay.\n\nI don't really understand what you are saying is worse - the very idea\nof accompanying the \"Aborting commit due to empty commit message\"\nerror with advice clarifying that you *can* in fact commit with an\nempty message? Or the specifics of the message I proposed?\n\nIt looks like we agree that the current behavior of aborting the\ncommit when an editor is popped up and closed empty, is one that we\nagree on, at least. I had not understood that from your initial \"I\nagree that we should do away with the check for the empty commit\nmessage.\" response.\n\nI assumed that at least some others in this thread intent on \"not\nchanging the behavior\" were reacting to the risk of *accidentally* or\n\"ignorantly\" creating messageless commits, rather than advocating for\ndoing away with the --allow-empty-message option altogether.\n\n>\n> I.e. that's really helping a user to mitigate a genuine mistake,\n> particularly if something goes wrong with the external editor. I.e. I\n> think something like this would be sufficient (as in, it should\n> succeed):\n>\n>     $ git commit -a --no-edit\n>     Aborting commit due to empty commit message.\n\nThat seems very reasonable to me, fwiw - it's hard to see how you do\n--no-edit by accident.\n\n>\n> All of those would be good cases to get feedback on, i.e. let's leave\n> aside the question of whether the UX should \"encourage\" and whether\n> --allow-empty-message should be the default, do the proponents of the\n> status quo think all of these are sensible:\n>\n>     git commit -a # launches editor\nYes - I believe that interactively prompting the user for a message is\nthe right thing.\n\n>     git commit -a -m\"\" # empty message\nYes - I believe that rejecting the empty message by default here is\nstill the right thing - there are many ways of doing this by accident,\nI believe we should require a more explicit signal of intent before\naccepting an empty message.\n\n>     git commit -a --no-edit # no editor\nNo - I agree \"--no-edit\" seems like a clear enough signal of intent\nthat we shouldn't *also* require --allow-empty-message\n\n>\n> Aside from anything else I think --allow-empty-message for that last one\n> is rather silly, it's basically making the user say\n> --yes-i-know-the-default-messages-is-the-empty-message. Maybe it's\n> arguably in the case of a pre-commit hook & without --no-verify?\n>\n> Anyway, that was a bit of a digression, sorry.\n>\n\nI don't believe it is a digression, at all. I think this thread could\nhead in a more productive direction if a series of specific measures\nwere proposed, each outlining what it hopes to achieve, and evaluated\neach on their merits.\n\n> The reason I think it's \"worse than the status quo\" is that it takes us\n> from something that seems to be an overzelous CLI option check gone\n> wrong to actively recommending a \"novice forever\" UX pattern. I.e. the\n> \"reduce the understandability of the commit history\" etc. assumes or\n> implies that we won't have a \"git rebase -i\" before pushing.\n>\n\nSo, it sounds like you don't believe the discoverability of\n\"--allow-empty-message\" is a significant concern, and the really\nimportant question here, the one you were referring to when you\nsuggested to \"do away with the check for the empty commit message\",\nwas the behavior when an empty message is \"more explicitly\" passed in,\nusing the \"--message\" or \"--file\" options...?\n\nFwiw, I think those patterns still very easily allow for *accidental*\nempty messages, and I would prefer to require a more explicit  signal\nof intent, and I would have thought *some* reasonably-worded advice\nwould remove the \"sting\" of having to do something different from \"-m\n''\". One other possibility I don't see discussed, is whether a\nsingle-letter flag for \"--allow-empty-message\" (or \"--no-edit\" would\nhelp. Several discussion participants noted they use garbage rather\nthan empty just to avoid typing so much...\n"},{"id":"453417","messageId":"xmqq4k2zjyb0.fsf@gitster.g","threadId":"57693","inReplyTo":"220411.865ynfkj7r.gmgdl@evledraar.gmail.com","subject":"Re: Make commit messages optional","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-11T17:59:47Z","receivedAt":"2022-04-11T18:00:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Fri, Apr 08 2022, Erik Cervin Edin wrote:\n>\n>> At the risk of bikeshedding.\n>>\n>> The case in favor of not allowing empty commit messages by default is\n>> that most of the time, empty commit messages are useless.\n>>\n>> I've written my fair share of poor commit messages (-,..., wip, foo).\n>> Sometimes I've fixed that retroactively, sometimes not. The advantage\n>> I see with empty commit messages is that it's more ubiquitous to\n>> \"write something better\" or \"whatever\". The downside is I can't git\n>> log --grep '^$' to find them.\n>\n> You can:\n>\n>     git log --invert-grep --grep '.'\n\nWow, that's nasty.\n\nIn any case, \"--allow-empty-messages\" exists, and that is where we\ndraw the line.  We will not bend over backwards beyond it.\n\nThanks.\n"},{"id":"453418","messageId":"xmqqzgkrijb0.fsf@gitster.g","threadId":"57693","inReplyTo":"CAPMMpohNYizpbqerAuFZnSY9mFsTJEJbfFWNGY41GcHxdwGrew@mail.gmail.com","subject":"Re: Make commit messages optional","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-11T18:09:07Z","receivedAt":"2022-04-11T18:09:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tao Klerks <tao@klerks.biz> writes:\n\n> Several discussion participants noted they use garbage rather\n> than empty just to avoid typing so much...\n\nIt is a positive thing, isn't it?\n\nIf they consistently use greppable garbage, that may serve as even\nbetter reminders that they need to revisit and clean them up later.\n"},{"id":"453419","messageId":"20220411181557.GE163591@kunlun.suse.cz","threadId":"57693","inReplyTo":"xmqqzgkrijb0.fsf@gitster.g","subject":"Re: Make commit messages optional","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2022-04-11T18:15:57Z","receivedAt":"2022-04-11T18:16:10Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Mon, Apr 11, 2022 at 11:09:07AM -0700, Junio C Hamano wrote:\n> Tao Klerks <tao@klerks.biz> writes:\n> \n> > Several discussion participants noted they use garbage rather\n> > than empty just to avoid typing so much...\n> \n> It is a positive thing, isn't it?\n> \n> If they consistently use greppable garbage, that may serve as even\n> better reminders that they need to revisit and clean them up later.\n\nUhh, that'e very contrived argument.\n\nWas that meant as a joke?\n\nMaybe you forgot your smiley faces.\n\nThanks\n\nMichal\n"},{"id":"453420","messageId":"20220411181819.GF163591@kunlun.suse.cz","threadId":"57693","inReplyTo":"xmqq4k2zjyb0.fsf@gitster.g","subject":"Re: Make commit messages optional","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2022-04-11T18:18:19Z","receivedAt":"2022-04-11T18:18:26Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Mon, Apr 11, 2022 at 10:59:47AM -0700, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> \n> > On Fri, Apr 08 2022, Erik Cervin Edin wrote:\n> >\n> >> At the risk of bikeshedding.\n> >>\n> >> The case in favor of not allowing empty commit messages by default is\n> >> that most of the time, empty commit messages are useless.\n> >>\n> >> I've written my fair share of poor commit messages (-,..., wip, foo).\n> >> Sometimes I've fixed that retroactively, sometimes not. The advantage\n> >> I see with empty commit messages is that it's more ubiquitous to\n> >> \"write something better\" or \"whatever\". The downside is I can't git\n> >> log --grep '^$' to find them.\n> >\n> > You can:\n> >\n> >     git log --invert-grep --grep '.'\n> \n> Wow, that's nasty.\n> \n> In any case, \"--allow-empty-messages\" exists, and that is where we\n> draw the line.  We will not bend over backwards beyond it.\n\nIsn't special-casing the empty message bending over backwards to some\nother influence instead?\n\nThanks\n\nMichal\n"},{"id":"453421","messageId":"YlRyHR5rvG5P/Acr@mit.edu","threadId":"57693","inReplyTo":"220411.861qy3khkk.gmgdl@evledraar.gmail.com","subject":"Re: Make commit messages optional","fromName":"tytso","fromEmail":"tytso@mit.edu","sentAt":"2022-04-11T18:23:25Z","receivedAt":"2022-04-11T18:23:59Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Apr 11, 2022 at 12:19:51PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> > and the main argument *against* is \"for most\n> > people (non-advanced users), what you do initially is what you end up\n> > pushing, or at least trying to push, and fixing things later is *hard*\n> > - it requires a much deeper understanding of git than most people\n> > otherwise necessarily need to develop\".\n> \n> Yes, maybe it won't be viable to go in that direction, but re this in my\n> [1]:\n> \t\n> \tBut I'm also pretty sure that those people are engaged in a proxy war,\n> \tand we should just attack the \"problem\" directly instead. I.e. it's not\n> \ta problem that some commit somewhere has an empty message, rather it's\n> \tthat such a commit gets \"propagated\". A better place to check for it is\n> \tthen at the point of point of propagation.\n\nSo possible options we could consider:\n\n1) Do nothing.  If users want to override the current behavior they\ncan just put in their .git/config or ~/.gitconfig file:\n\n[alias]\n   commit = commit --allow-empty-message\n\n2) Add some kind of explicit git-config option which could then be\nadded to their .git/config or ~/.gitconfig:\n\n[commit]\n   allow-empty-description = true\n\n3) Change the default, so that --allow-empty-message is always\nimplied, and hope that novices can figure out git rebase -i without\nshooting themselves in the foot.\n\n4) Enforce git push doesn't push commits with empty commits,\nimplemented on the client side.  This could be implemented via a\npre-push hook script.\n\n5)  Enforce git push doesn't push commits with empty commits,\nimplemented on the server side.This could be implemented via a\npre-receive hook script.\n\nI will note that only options 2 and 3 require source code changes to\ngit.  The rest can effectively be done via config file changes; for\nthe hook files, we could provide example scripts to make it easier for\npeople to choose that particular option.\n\nAnd of these options, only one option, #3, requires imposing someone's\npreference (which does appear to be in the minority) on everyone\nelse.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"453429","messageId":"220411.86k0bvidja.gmgdl@evledraar.gmail.com","threadId":"57693","inReplyTo":"YlRyHR5rvG5P/Acr@mit.edu","subject":"Re: Make commit messages optional","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-11T20:10:23Z","receivedAt":"2022-04-11T20:13:51Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Apr 11 2022, tytso wrote:\n\n> On Mon, Apr 11, 2022 at 12:19:51PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>> > and the main argument *against* is \"for most\n>> > people (non-advanced users), what you do initially is what you end up\n>> > pushing, or at least trying to push, and fixing things later is *hard*\n>> > - it requires a much deeper understanding of git than most people\n>> > otherwise necessarily need to develop\".\n>> \n>> Yes, maybe it won't be viable to go in that direction, but re this in my\n>> [1]:\n>> \t\n>> \tBut I'm also pretty sure that those people are engaged in a proxy war,\n>> \tand we should just attack the \"problem\" directly instead. I.e. it's not\n>> \ta problem that some commit somewhere has an empty message, rather it's\n>> \tthat such a commit gets \"propagated\". A better place to check for it is\n>> \tthen at the point of point of propagation.\n>\n> So possible options we could consider:\n>\n> 1) Do nothing.  If users want to override the current behavior they\n> can just put in their .git/config or ~/.gitconfig file:\n>\n> [alias]\n>    commit = commit --allow-empty-message\n\nYou cannot use aliases to override built-in commands, so this won't\nwork.\n\n> 2) Add some kind of explicit git-config option which could then be\n> added to their .git/config or ~/.gitconfig:\n>\n> [commit]\n>    allow-empty-description = true\n>\n> 3) Change the default, so that --allow-empty-message is always\n> implied, and hope that novices can figure out git rebase -i without\n> shooting themselves in the foot.\n>\n> 4) Enforce git push doesn't push commits with empty commits,\n> implemented on the client side.  This could be implemented via a\n> pre-push hook script.\n>\n> 5)  Enforce git push doesn't push commits with empty commits,\n> implemented on the server side.This could be implemented via a\n> pre-receive hook script.\n>\n> I will note that only options 2 and 3 require source code changes to\n> git.  The rest can effectively be done via config file changes; for\n> the hook files, we could provide example scripts to make it easier for\n> people to choose that particular option.\n>\n> And of these options, only one option, #3, requires imposing someone's\n> preference (which does appear to be in the minority) on everyone\n> else.\n\nWe could add configuration or whatever, but the topic of this thread is\nwhether we should change the *default*. I think it's better to stick to\nthat.\n"},{"id":"453430","messageId":"xmqq1qy3gwd9.fsf@gitster.g","threadId":"57693","inReplyTo":"20220411181819.GF163591@kunlun.suse.cz","subject":"Re: Make commit messages optional","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-11T21:09:54Z","receivedAt":"2022-04-11T21:10:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michal Suchánek <msuchanek@suse.de> writes:\n\n>> In any case, \"--allow-empty-messages\" exists, and that is where we\n>> draw the line.  We will not bend over backwards beyond it.\n>\n> Isn't special-casing the empty message bending over backwards to some\n> other influence instead?\n\nNot at all.\n\nEven though the low level plumbing commands try to be accomodating\nto people with different tastes, the Porcelain layer is opinionated\nitself, and tries to give defaults that encourage good development\npractice to interactive users.  There is no need for some other\ninfluence---we chose to reject creating commits with empty messages\nto prevent mistakes that novices may find hard to recover from,\nand that's final.\n\n\n\n"},{"id":"453472","messageId":"YlZiQemrAuryF0vv@google.com","threadId":"57693","inReplyTo":"CAPMMpohnwTTwTEjr9u29O_qVJtQNuG29G3Ta+-rXz-De8zvMCQ@mail.gmail.com","subject":"Re: Make commit messages optional","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2022-04-13T05:40:17Z","receivedAt":"2022-04-13T05:40:34Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nTao Klerks wrote:\n> On Sun, Apr 10, 2022 at 5:18 PM <rsbecker@nexbridge.com> wrote:\n\n>> And I still don't get why the --allow-empty-message is not\n>> sufficient to meet your use case. git supports what is being\n>> requested already, not that it is allowed where I am. Are we\n>> talking about setting --allow-empty-message as the default? That is\n>> a major behavioural change. You could create a git command alias to\n>> always specify this option. So what is the point of this?\n>>\n>\n> My proposal is that it absolutely is enough, functionally - but the\n> abundance of \"we should change something\" concerns in this thread and\n> elsewhere suggest, to me, that it might not be sufficiently\n> discoverable; hence the \"advice\" proposal.\n\nThanks for this point.  I find it to be a very reasonable one.  I'd be\nhappy to review a patch adding an advice item when people use options\nlike '-m \"\"'.\n\nSincerely,\nJonathan\n"},{"id":"453652","messageId":"YlgzrSAJnYpNYDV0@mit.edu","threadId":"57693","inReplyTo":"220411.86k0bvidja.gmgdl@evledraar.gmail.com","subject":"Re: Make commit messages optional","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2022-04-14T14:46:05Z","receivedAt":"2022-04-14T15:47:34Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Apr 11, 2022 at 10:10:23PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> \n> We could add configuration or whatever, but the topic of this thread is\n> whether we should change the *default*. I think it's better to stick to\n> that.\n\nI would have thought it was painfully obvious that changing the\n*default* is a ***terrible*** idea?\n\nIs anyone other than the OP seriously promoting changing the default?\n\nIf someone wants to do something terrible to their own development\nworkflow (or if it actually makes sense for their workflow) we could\nadd some configuration, but if the question is changing the default,\nmy ppersonal opinion is, \"Heck, no!\"\n\n   \t  \t     \t    \t      - Ted\n"},{"id":"453658","messageId":"220414.86czhjd35w.gmgdl@evledraar.gmail.com","threadId":"57693","inReplyTo":"YlgzrSAJnYpNYDV0@mit.edu","subject":"Re: Make commit messages optional","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-14T16:43:10Z","receivedAt":"2022-04-14T17:03:22Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Apr 14 2022, Theodore Ts'o wrote:\n\n> On Mon, Apr 11, 2022 at 10:10:23PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>> \n>> We could add configuration or whatever, but the topic of this thread is\n>> whether we should change the *default*. I think it's better to stick to\n>> that.\n>\n> I would have thought it was painfully obvious that changing the\n> *default* is a ***terrible*** idea?\n>\n> Is anyone other than the OP seriously promoting changing the default?\n\nUrm, yeah? I am, in the E-Mail upthread that replied to. The OP here is\njurgen_gjoncari@icloud.com.\n\n> If someone wants to do something terrible to their own development\n> workflow (or if it actually makes sense for their workflow) we could\n> add some configuration, but if the question is changing the default,\n> my ppersonal opinion is, \"Heck, no!\"\n\nI think you're almost certainly correct that there's worthwhile things\nwe can catch with the current default.\n\nI just suspect that we can do so much more effectively and encourage\nmore effectivey workflows by doing so at the point of propagation, not\ncommit.\n"},{"id":"453660","messageId":"xmqqh76v1ssd.fsf@gitster.g","threadId":"57693","inReplyTo":"220414.86czhjd35w.gmgdl@evledraar.gmail.com","subject":"Re: Make commit messages optional","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-14T17:25:22Z","receivedAt":"2022-04-14T17:25:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Thu, Apr 14 2022, Theodore Ts'o wrote:\n>\n>> I would have thought it was painfully obvious that changing the\n>> *default* is a ***terrible*** idea?\n>>\n>> Is anyone other than the OP seriously promoting changing the default?\n>\n> Urm, yeah? I am, in the E-Mail upthread that replied to. The OP here is\n> jurgen_gjoncari@icloud.com.\n\nPretend this message never happend; you are the last person who gave\na valuable opinion in this thread, and be happy now.\n\n> ...\n> I just suspect that we can do so much more effectively and encourage\n> more effectivey workflows by doing so at the point of propagation, not\n> commit.\n\nWe are talking about \"git commit\" Porcelain.  Our Porcelain layer is\nopinionated and designed to help non-expert interactive users by\nencouraging the best-current-practice.  And what we consider BCP for\nnon-experts is to have a workable if not perfect history without\npost polishing with \"rebase -i\" and friends, as we know it is\nunrealistic to expect pre-push and receive hook gates to be set up\nadequately in environments where non-experts work.\n\nLet's stop talking about changing the default of \"git commit\" here\n(eh, not here, but one message before this, so you're the last who\nspoke).  I won't stop people from coming up with an alternative that\nis built from plumbing commands and does not require log message by\ndefault, and maintain such a \"git better-commit\" out of my tree.\n\nThanks.\n"}]}