{"thread":{"id":"4336","subject":"[PATCH] Automatically line wrap long commit messages.","startedAt":"2006-05-29T08:57:39Z","lastAt":"2006-06-01T06:37:13Z","messageCount":10,"participants":["Shawn Pearce","Jan-Benedict Glaw","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"20878","messageId":"20060529085738.GB29500@spearce.org","threadId":"4336","inReplyTo":null,"subject":"[PATCH] Automatically line wrap long commit messages.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-29T08:57:39Z","receivedAt":"2006-05-29T08:57:39Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"When using -m on the command line with git-commit it is not uncommon\nfor a long commit message to be entered without line terminators.\nThis creates commit objects whose messages are not readable in\n'git log' as the line runs off the screen.\n\nSo instead reformat log messages if they are supplied on the\ncommand line.\n\nSigned-off-by: Shawn O. Pearce \n---\n This one might cause some problems for people. It requires\n 'fmt' in order to use log messages on the command line as well as\n some users may not like having their log messages line wrapped.\n I'm open to suggestions for how to deal with this but personally\n this is one feature which I put into pg's commit tool that I miss\n dearly when working with core GIT.\n\n git-commit.sh | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex a092b72..e7aa4b1 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -547,7 +547,12 @@ fi\n \n if test \"$log_message\" != ''\n then\n-\techo \"$log_message\"\n+\t# The message came from the command line. It might contain very\n+\t# long lines so reformat it with a target of 60. Note that we\n+\t# don't reformat messages created in an editor by the user as\n+\t# we should assume they carefully formatted it in some way.\n+\t#\n+\techo \"$log_message\" | fmt -w 60\n elif test \"$logfile\" != \"\"\n then\n \tif test \"$logfile\" = -\n-- \n1.3.3.g45d8\n"},{"id":"20880","messageId":"20060529090045.GW13513@lug-owl.de","threadId":"4336","inReplyTo":"20060529085738.GB29500@spearce.org","subject":"Re: [PATCH] Automatically line wrap long commit messages.","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-05-29T09:00:45Z","receivedAt":"2006-05-29T09:00:45Z","isPatch":true,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Mon, 2006-05-29 04:57:39 -0400, Shawn Pearce wrote:\n> When using -m on the command line with git-commit it is not uncommon\n> for a long commit message to be entered without line terminators.\n> This creates commit objects whose messages are not readable in\n> 'git log' as the line runs off the screen.\n\nUh? Just put it in quotes and press the Enter key when applicable.\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"20881","messageId":"20060529091423.GD29500@spearce.org","threadId":"4336","inReplyTo":"20060529090045.GW13513@lug-owl.de","subject":"Re: [PATCH] Automatically line wrap long commit messages.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-29T09:14:23Z","receivedAt":"2006-05-29T09:14:23Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jan-Benedict Glaw wrote:\n> On Mon, 2006-05-29 04:57:39 -0400, Shawn Pearce wrote:\n> > When using -m on the command line with git-commit it is not uncommon\n> > for a long commit message to be entered without line terminators.\n> > This creates commit objects whose messages are not readable in\n> > 'git log' as the line runs off the screen.\n> \n> Uh? Just put it in quotes and press the Enter key when applicable.\n\nI realize that. But I feel that it looks rather ugly on the command\nline, in the resulting message, and is difficult to do well all of\nthe time.\n\nFor one thing the first line is offset due to the stuff preeceding\nit on the command line, even if you put the -m\" on the next line.\nFor another it goes nicely with my prior patch of allowing multiple\n-m flags on the command line and merging them into a single commit\nmessage by treating each option argument as its own paragraph.\n\nMaybe its just me but I've generally found `fmt` does a nice job\nof line wrapping my text. I'm writing this email out in vi with\nno thought to line wrapping and will let `fmt` clean it all up for\nme before I sent it. I do the same thing with all of my commit\nmessages; except git-commit won't let me do it from the command line.\n\nThis patch was trying to do that... but I suspected some folks\nwould not like the idea very much. :-)\n\n-- \nShawn.\n"},{"id":"20882","messageId":"7virnp8a30.fsf@assigned-by-dhcp.cox.net","threadId":"4336","inReplyTo":"20060529085738.GB29500@spearce.org","subject":"Re: [PATCH] Automatically line wrap long commit messages.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-29T09:16:35Z","receivedAt":"2006-05-29T09:16:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> When using -m on the command line with git-commit it is not uncommon\n> for a long commit message to be entered without line terminators.\n> This creates commit objects whose messages are not readable in\n> 'git log' as the line runs off the screen.\n>\n> So instead reformat log messages if they are supplied on the\n> command line.\n>\n> Signed-off-by: Shawn O. Pearce \n> ---\n> This one might cause some problems for people.\n\nI am already moderately negative on multiple -m so in the light\nof it this one looks totally unneeded. You could do a number of\nthings:\n\n\t$ git commit -m 'This is my message.\n\n\tThis is the first line of the message body.'\n $ cat >L < wrote:\n> Shawn Pearce writes:\n> \n> > When using -m on the command line with git-commit it is not uncommon\n> > for a long commit message to be entered without line terminators.\n> > This creates commit objects whose messages are not readable in\n> > 'git log' as the line runs off the screen.\n> >\n> > So instead reformat log messages if they are supplied on the\n> > command line.\n> >\n> > Signed-off-by: Shawn O. Pearce \n> > ---\n> > This one might cause some problems for people.\n> \n> I am already moderately negative on multiple -m so in the light\n> of it this one looks totally unneeded. You could do a number of\n> things:\n[snip]\n\nOK. Ignore both patches then. Two negative votes in such a short\ntime suggests they are probably not generally accepted. ;-)\n\n> We probably should allow \"commit -F -\" to read from the standard\n> input if we already don't, but that is about as far as I am\n> willing to go at this moment.\n\nWe do. So apparently the solution to my usage issue is:\n\n\t$ fmt -w 60 | git commit -F-\n\tThis is my message.\n\n\tThis is the body. Etc....\n\tEOF\n\nI'm thinking that's too much work for me. Which means either I\nlearn to format my messages better in a single -m switch (as was\nalready suggested) or I just deal with git-commit popping open\n$EDITOR anytime I want to commit something. In which case then I\nmight as well also get a diff of what I am about to commit as part\nof the temp file buffer.\n\nOr I create my own little wrapper shell script which calls fmt.\nHmm, maybe that would be useful with alias and a promise to not\nuse ci as a core GIT command name:\n\n\t[alias \"ci\"]\n\t\tcommand=shawns-commit-wrapper\n\n-- \nShawn.\n"},{"id":"20963","messageId":"7vhd373o15.fsf@assigned-by-dhcp.cox.net","threadId":"4336","inReplyTo":"20060529094605.GB27194@spearce.org","subject":"Re: [PATCH] Automatically line wrap long commit messages.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-30T08:38:46Z","receivedAt":"2006-05-30T08:38:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> OK. Ignore both patches then. Two negative votes in such a short\n> time suggests they are probably not generally accepted. ;-)\n>\n>> We probably should allow \"commit -F -\" to read from the standard\n>> input if we already don't, but that is about as far as I am\n>> willing to go at this moment.\n>\n> We do. So apparently the solution to my usage issue is:\n>\n> \t$ fmt -w 60 | git commit -F-\n> \tThis is my message.\n>\n> \tThis is the body. Etc....\n> \tEOF\n>\n> I'm thinking that's too much work for me.\n\nIf we supported multiple -m (presumably each becomes a single line?)\nwith internal fmt, I do not see how it would become less work.\n\n\t$ git commit -w60 -m \"This is my message.\" \\\n \t-m '' \\\n \t-m 'This is the body. Etc....'\n\nlooks more typing to me, even without the second line to force\nthe empty line between the summary and the body.\n"},{"id":"20995","messageId":"20060531021808.GC21222@spearce.org","threadId":"4336","inReplyTo":"7vhd373o15.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Automatically line wrap long commit messages.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-31T02:18:08Z","receivedAt":"2006-05-31T02:18:08Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Shawn Pearce writes:\n> \n> > OK. Ignore both patches then. Two negative votes in such a short\n> > time suggests they are probably not generally accepted. ;-)\n> >\n> >> We probably should allow \"commit -F -\" to read from the standard\n> >> input if we already don't, but that is about as far as I am\n> >> willing to go at this moment.\n> >\n> > We do. So apparently the solution to my usage issue is:\n> >\n> > \t$ fmt -w 60 | git commit -F-\n> > \tThis is my message.\n> >\n> > \tThis is the body. Etc....\n> > \tEOF\n> >\n> > I'm thinking that's too much work for me.\n> \n> If we supported multiple -m (presumably each becomes a single line?)\n> with internal fmt, I do not see how it would become less work.\n> \n> \t$ git commit -w60 -m \"This is my message.\" \\\n> \t-m '' \\\n> \t-m 'This is the body. Etc....'\n> \n> looks more typing to me, even without the second line to force\n> the empty line between the summary and the body.\n\nActually I was thinking each -m would be its own paragraph so blank\nlines would split each -m and maybe the -w60 should be a config\noption in .git/config or .gitrc so it doesn't always need to be\nsupplied on the command line.\n\nPersonally I want blank lines between each -m and to always run\nthe message through fmt. Others may want to run their commit\nmessages through other filters so maybe the filter itself is just\na config value which gets executed:\n\n\t[user]\n\t\tcommitMessageFilter = fmt -w 60\n\nor someone else might set:\n\n\t[user]\n\t\tcommitMessageFilter = /home/user/bin/my-filter\n\nwhere the filter accepts the message on STDIN and writes (the maybe\nchanged) message on STDOUT.\n\n-- \nShawn.\n"},{"id":"20998","messageId":"7v64jm2380.fsf@assigned-by-dhcp.cox.net","threadId":"4336","inReplyTo":"20060531021808.GC21222@spearce.org","subject":"Re: [PATCH] Automatically line wrap long commit messages.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-31T05:05:51Z","receivedAt":"2006-05-31T05:05:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Junio C Hamano wrote:\n>\n>> If we supported multiple -m (presumably each becomes a single line?)\n>> with internal fmt, I do not see how it would become less work.\n>> \n>> \t$ git commit -w60 -m \"This is my message.\" \\\n>> \t-m '' \\\n>> \t-m 'This is the body. Etc....'\n>> \n>> looks more typing to me, even without the second line to force\n>> the empty line between the summary and the body.\n>\n> Actually I was thinking each -m would be its own paragraph so blank\n> lines would split each -m and maybe the -w60 should be a config\n> option in .git/config or .gitrc so it doesn't always need to be\n> supplied on the command line.\n\nNow that makes the distinction between the current:\n\n\t$ git commit -m 'This is my message.\n\n\tThis is the body. Etc....'\n\nvs. the proposed multi-em:\n\n\t$ git commit -m 'This is my message.' \\\n -m 'This is the body. Etc....'\n\nPresumably Etc.... will be an multiline argument to -m. The\ndistinction is even more blurry to me than before.\n\nEmacs users would just do \"ESC q\" and vi users would know how to\nfilter the file contents through fmt, so this seems to come from\naversion against invoking your $EDITOR. I just do not see why.\n\nHaving said that, I do realize that the current behaviour of\naccepting multiple -m without complaining and discarding all but\nthe last one silently is far worse than what is being proposed,\nand I do not see downside to the multiple -m patch, so let's\napply that. You can have your \"fmt -w60\" provided if it is made\ninto an option.\n"},{"id":"21044","messageId":"20060601033430.GA13485@spearce.org","threadId":"4336","inReplyTo":"7v64jm2380.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Automatically line wrap long commit messages.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-06-01T03:34:30Z","receivedAt":"2006-06-01T03:34:30Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Shawn Pearce writes:\n> \n> > Junio C Hamano wrote:\n> >\n> >> If we supported multiple -m (presumably each becomes a single line?)\n> >> with internal fmt, I do not see how it would become less work.\n> >> \n> >> \t$ git commit -w60 -m \"This is my message.\" \\\n> >> \t-m '' \\\n> >> \t-m 'This is the body. Etc....'\n> >> \n> >> looks more typing to me, even without the second line to force\n> >> the empty line between the summary and the body.\n> >\n> > Actually I was thinking each -m would be its own paragraph so blank\n> > lines would split each -m and maybe the -w60 should be a config\n> > option in .git/config or .gitrc so it doesn't always need to be\n> > supplied on the command line.\n> \n> Now that makes the distinction between the current:\n> \n> \t$ git commit -m 'This is my message.\n> \n> \tThis is the body. Etc....'\n> \n> vs. the proposed multi-em:\n> \n> \t$ git commit -m 'This is my message.' \\\n> -m 'This is the body. Etc....'\n> \n> Presumably Etc.... will be an multiline argument to -m. The\n> distinction is even more blurry to me than before.\n> \n> Emacs users would just do \"ESC q\" and vi users would know how to\n> filter the file contents through fmt, so this seems to come from\n> aversion against invoking your $EDITOR. I just do not see why.\n\nBecause git-commit currently performs a status update and throws\nthat data into the editor buffer. That takes longer than committing\nfrom the command line. Especially if I've just done a git-diff or\ngit-status to see what is changed and about to be committed...\n\nOn a project the size of GIT on a Unix system this isn't a big deal;\non a 9000 file project on Cygwin this difference is significant\nto me.\n\nIt is just the way I am used to working.\n\n> Having said that, I do realize that the current behaviour of\n> accepting multiple -m without complaining and discarding all but\n> the last one silently is far worse than what is being proposed,\n> and I do not see downside to the multiple -m patch, so let's\n> apply that. You can have your \"fmt -w60\" provided if it is made\n> into an option.\n\nI'll rework the fmt -w60 patch to instead accept an optional filter\ncommand from .git/config; if the filter command is set then the\ncommand line commit message will get run through the filter before\nbeing piped into git-commit-tree.\n\n-- \nShawn.\n"},{"id":"21045","messageId":"7v3beptm92.fsf@assigned-by-dhcp.cox.net","threadId":"4336","inReplyTo":"20060601033430.GA13485@spearce.org","subject":"Re: [PATCH] Automatically line wrap long commit messages.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-01T06:37:13Z","receivedAt":"2006-06-01T06:37:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Because git-commit currently performs a status update and throws\n> that data into the editor buffer. That takes longer than committing\n> from the command line. Especially if I've just done a git-diff or\n> git-status to see what is changed and about to be committed...\n\nAh, why does it take this many exchanges to extract the true\nmotive behind what people do even in a technical forum like\nthis, I wonder...\n\nSo what you want is not multiple -m options nor piping to fmt.\nWhat you really want is an option that is the opposite of -v to\ngit-commit that omits the status list (\"_could_ commit if you\nupdate-index\" part -- since \"will commit\" is something we would\nneed to compute anyway).\n\n> On a project the size of GIT on a Unix system this isn't a big deal;\n> on a 9000 file project on Cygwin this difference is significant\n> to me.\n\nI suspect you are suffering from lstat() performance. I wonder\nif \"assume unchanged\" git help your situation?\n"}]}