{"thread":{"id":"11364","subject":"git rebase -i / git-gui bug","startedAt":"2007-12-20T00:35:28Z","lastAt":"2007-12-30T15:50:17Z","messageCount":28,"participants":["Bernt Hansen","Shawn O. Pearce","Junio C Hamano","Matthieu Moy","Johannes Schindelin","しらいしななこ"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"63823","messageId":"87ve6ub3u7.fsf@gollum.intra.norang.ca","threadId":"11364","inReplyTo":null,"subject":"git rebase -i / git-gui bug","fromName":"Bernt Hansen","fromEmail":"bernt@alumni.uwaterloo.ca","sentAt":"2007-12-20T00:35:28Z","receivedAt":"2007-12-20T00:35:28Z","isPatch":false,"sender":{"key":"bernt@norang.ca","avatar":null},"body":"Thanks for a great tool I use everyday!\n\nI'm using the tip of master for my regular day job with git-gui to write\nthe commit messages. I've run into a little glitch with git rebase -i\nand git-gui.\n\n$ git --version\ngit version 1.5.4.rc0.73.gce85b\n\nI haven't been able to automate the process of reproducing this but the\nsteps are fairly simple.\n\nTo show the problem you can create a test repository using the following\nscript:\n\n--- t1.sh ---\n#!/bin/sh\ncd /tmp\nmkdir t1\ncd t1\ngit init\n\nfor F in f1 f2 f3 f4 f5 f6 f7 f8 f9 f10; do\n echo $F >$F\n git add $F\n echo -n -e \"Commit for $F\\n\\nThis is line one\\nThis is line two\" >/tmp/commitmsg.txt \n git commit -F /tmp/commitmsg.txt\ndone\n-------------\n\nNow cd /tmp/t1 and do the following:\n\n$ git rebase -i HEAD~9\n\nChange all lines with 'pick' to 'edit'\n\nFor each of the 10 commits use git-gui to select 'Amend Last Commit' and\njust hit the [Commit] button (you can change the text if you want but\nit's not necessary to show the problem)\n\n$ git rebase --continue\nafter each commit and repeat until the rebase is complete.\n\nNow if you try to squash these commits the edit buffer commit text is a\nlittle mangled.\n\n$ git rebase -i HEAD~9\n\nChange all but the first pick line to 'squash' and I get the following\ntext in the commit message edit window:\n\n----[ /tmp/t1/.git/COMMIT_EDITMSG ]----\n# This is a combination of 3 commits.\n# The first commit's message is:\n\nCommit for f2\n\nThis is line one\nThis is line two\n# This is the 2nd commit message:\n\nCommit for f3\n\nThis is line one\nThis is line two# This is the 3rd commit message:\n\nCommit for f4\n\nThis is line one\nThis is line two# This is the 3rd commit message:\n\nCommit for f5\n\nThis is line one\nThis is line two# This is the 3rd commit message:\n\nCommit for f6\n\nThis is line one\nThis is line two# This is the 3rd commit message:\n\nCommit for f7\n\nThis is line one\nThis is line two# This is the 3rd commit message:\n\nCommit for f8\n\nThis is line one\nThis is line two# This is the 3rd commit message:\n\nCommit for f9\n\nThis is line one\nThis is line two# This is the 3rd commit message:\n\nCommit for f10\n\nThis is line one\nThis is line two\n\n# Please enter the commit message for your changes.\n# (Comment lines starting with '#' will not be included)\n# Not currently on any branch.\n# Changes to be committed:\n# (use \"git reset HEAD ...\" to unstage)\n#\n#\tnew file: f10\n#\tnew file: f2\n#\tnew file: f3\n#\tnew file: f4\n#\tnew file: f5\n#\tnew file: f6\n#\tnew file: f7\n#\tnew file: f8\n#\tnew file: f9\n#\n---------------------------------------\n\nNotice after the 3rd commit the '# This is the 3rd commit message:' is\nappended to the last line of the previous commit message and the counter\nseems to be stuck on 3.\n\n---\n\nWhen I run into this during work I fix up the commit text by adding\nnewlines before the '# This is the 3rd commit message' and it works\nfine.\n\nThis might be the lack of a newline after the last line in the commit\nedit message when git-gui creates the commit -- maybe.\n\nIf I use git --amend instead of git-gui to update the commits on the\nabove test repository it works correctly.\n\nI'm posting this because someone else can probably fix this faster than\nme (I've never looked at the git source code). I'll post a patch when I\nfigure it out if nobody else beats me to it.\n\nRegards,\nBernt\n"},{"id":"63832","messageId":"87r6hias5s.fsf@gollum.intra.norang.ca","threadId":"11364","inReplyTo":"87ve6ub3u7.fsf@gollum.intra.norang.ca","subject":"Re: git rebase -i / git-gui bug","fromName":"Bernt Hansen","fromEmail":"bernt@alumni.uwaterloo.ca","sentAt":"2007-12-20T04:47:43Z","receivedAt":"2007-12-20T04:47:43Z","isPatch":false,"sender":{"key":"bernt@norang.ca","avatar":null},"body":"Bernt Hansen writes:\n\n> Now cd /tmp/t1 and do the following:\n>\n> $ git rebase -i HEAD~9\n>\n> Change all lines with 'pick' to 'edit'\n>\n> For each of the 10 commits use git-gui to select 'Amend Last Commit' and\n> just hit the [Commit] button (you can change the text if you want but\n> it's not necessary to show the problem)\n>\n> $ git rebase --continue\n> after each commit and repeat until the rebase is complete.\n>\n\nI can't do this at all with\n\n$ git --version\ngit version 1.5.4.rc1\n\nIf I\n\n$ git rebase -i HEAD~9\n\nand use git-gui to edit the commit then git-rebase --continue fails\n\n$ git rebase --continue\nCould not commit staged changes.\n\n-Bernt\n"},{"id":"63837","messageId":"20071220071212.GA20534@spearce.org","threadId":"11364","inReplyTo":"87r6hias5s.fsf@gollum.intra.norang.ca","subject":"[PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-20T07:12:12Z","receivedAt":"2007-12-20T07:12:12Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"During git-rebase --interactive's --continue implementation we used\nto silently restart the rebase if the user had made the commit\nfor us. This is common if the user stops to edit a commit and\ndoes so by amending it. My recent change to watch git-commit's\nexit status broke this behavior.\n\nThanks to Bernt Hansen for catching it in 1.5.4-rc1.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-rebase--interactive.sh | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 47581ce..39f32b1 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -372,8 +372,9 @@ do\n \t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n \t\t} &&\n \t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n-\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n+\t\tif ! git commit --no-verify -F \"$DOTEST\"/message -e\n \t\t\tdie \"Could not commit staged changes.\"\n+\t\tfi\n \n \t\trequire_clean_work_tree\n \t\tdo_rest\n-- \n1.5.4.rc1.1090.gab2276\n"},{"id":"63838","messageId":"7vzlw5rg53.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"20071220071212.GA20534@spearce.org","subject":"Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-20T07:15:20Z","receivedAt":"2007-12-20T07:15:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> During git-rebase --interactive's --continue implementation we used\n> to silently restart the rebase if the user had made the commit\n> for us. This is common if the user stops to edit a commit and\n> does so by amending it. My recent change to watch git-commit's\n> exit status broke this behavior.\n>\n> Thanks to Bernt Hansen for catching it in 1.5.4-rc1.\n>\n> Signed-off-by: Shawn O. Pearce \n> ---\n> git-rebase--interactive.sh | 3 ++-\n> 1 files changed, 2 insertions(+), 1 deletions(-)\n>\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index 47581ce..39f32b1 100755\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -372,8 +372,9 @@ do\n> \t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n> \t\t} &&\n> \t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> -\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n> +\t\tif ! git commit --no-verify -F \"$DOTEST\"/message -e\n> \t\t\tdie \"Could not commit staged changes.\"\n> +\t\tfi\n\nThis looks like a syntax error to me.\n"},{"id":"63840","messageId":"20071220073113.GJ14735@spearce.org","threadId":"11364","inReplyTo":"7vzlw5rg53.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-20T07:31:14Z","receivedAt":"2007-12-20T07:31:14Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> > index 47581ce..39f32b1 100755\n> > --- a/git-rebase--interactive.sh\n> > +++ b/git-rebase--interactive.sh\n> > @@ -372,8 +372,9 @@ do\n> > \t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n> > \t\t} &&\n> > \t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> > -\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n> > +\t\tif ! git commit --no-verify -F \"$DOTEST\"/message -e\n> > \t\t\tdie \"Could not commit staged changes.\"\n> > +\t\tfi\n> \n> This looks like a syntax error to me.\n\nWhoops. This looks like a syntax error to me too.\n\nIts late. I totally missed a \"then\". Would you mind doing an amend?\n\n-- \nShawn.\n"},{"id":"63842","messageId":"vpqodcl247e.fsf@bauges.imag.fr","threadId":"11364","inReplyTo":"20071220071212.GA20534@spearce.org","subject":"Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-12-20T07:52:21Z","receivedAt":"2007-12-20T07:52:21Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> -\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n ^\nWouldn't it be sufficient to add a backslash here ----------------' ?\n\n> +\t\tif ! git commit --no-verify -F \"$DOTEST\"/message -e\n> \t\t\tdie \"Could not commit staged changes.\"\n> +\t\tfi\n> \n> \t\trequire_clean_work_tree\n> \t\tdo_rest\n\n-- \nMatthieu\n"},{"id":"63844","messageId":"7vy7bppv3s.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"20071220073113.GJ14735@spearce.org","subject":"Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-20T09:35:03Z","receivedAt":"2007-12-20T09:35:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Will do, but the code looks quite bad (not entirely your fault).\n\nLine by line comment to show my puzzlement.\n\n \t\t# commit if necessary\n\nOk, the user has prepared the index for us, and we are going to do some\ntests and conditionally create commit.\n\n \t\tgit rev-parse --verify HEAD > /dev/null &&\n\nDo we have HEAD commit? Why check this --- we do not want to rebase\nfrom the beginning of time? No, that's not it. If this fails, there is\nsomething seriously wrong. This is not about \"will we make a commit?\"\ncheck at all. This is a basic sanity check and if it fails we must\nabort, not just skip.\n\n \t\tgit update-index --refresh &&\n \t\tgit diff-files --quiet &&\n\nIs the work tree clean with respect to the index? Why check this --- we\nwant to skip the commit if work tree is dirty? Or is this trying to\nenforce the invariant that during the rebase the work tree and index and\nHEAD should all match? If the latter, failure from this again is a\nreason to abort.\n\n \t\t! git diff-index --cached --quiet HEAD -- &&\n\nDo we have something to commit? This needs to be checked so that we can\nskip a commit that results in emptyness, so using this as a check to see\nif we should commit makes sense.\n\n \t\t. \"$DOTEST\"/author-script && {\n \t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n \t\t} &&\n\nFind GIT_AUTHOR_* variables and if we are amending rewind the HEAD. The\nfailure from this is a grave problem and reason to abort, isn't it?\n\n \t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n\t\tgit commit --no-verify -F \"$DOTEST\"/message -e\n\nThen we go on to create commit. As you said, failure from this is a\ngrave error.\n\nIf my commentary above is right, how many bugs did we find in these 10\nlines?\n\nGrumpy I am...\n\n---\n git-rebase--interactive.sh | 29 +++++++++++++++++++----------\n 1 files changed, 19 insertions(+), 10 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 090c3e5..7aa4278 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -363,17 +363,26 @@ do\n \n \t\ttest -d \"$DOTEST\" || die \"No interactive rebase running\"\n \n-\t\t# commit if necessary\n-\t\tgit rev-parse --verify HEAD > /dev/null &&\n-\t\tgit update-index --refresh &&\n-\t\tgit diff-files --quiet &&\n-\t\t! git diff-index --cached --quiet HEAD -- &&\n-\t\t. \"$DOTEST\"/author-script && {\n-\t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n-\t\t} &&\n-\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n-\t\tif ! git commit --no-verify -F \"$DOTEST\"/message -e\n+\t\t# Sanity check\n+\t\tgit rev-parse --verify HEAD >/dev/null ||\n+\t\t\tdie \"Cannot read HEAD\"\n+\t\tgit update-index --refresh && git diff-files --quiet ||\n+\t\t\tdie \"Working tree is dirty\"\n+\n+\t\t# do we have anything to commit?\n+\t\tif git diff-index --cached --quiet HEAD --\n \t\tthen\n+\t\t\t: Nothing to commit -- skip this\n+\t\telse\n+\t\t\t. \"$DOTEST\"/author-script ||\n+\t\t\t\tdie \"Cannot find the author identity\"\n+\t\t\tif test -f \"$DOTEST\"/amend\n+\t\t\tthen\n+\t\t\t\tgit reset --soft HEAD^ ||\n+\t\t\t\tdie \"Cannot rewind the HEAD\"\n+\t\t\tfi\n+\t\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n+\t\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n \t\t\tdie \"Could not commit staged changes.\"\n \t\tfi\n \n"},{"id":"64076","messageId":"8763yof9lg.fsf@gollum.intra.norang.ca","threadId":"11364","inReplyTo":"87ve6ub3u7.fsf@gollum.intra.norang.ca","subject":"[PATCH] Force new line at end of commit message","fromName":"Bernt Hansen","fromEmail":"bernt@alumni.uwaterloo.ca","sentAt":"2007-12-24T14:31:07Z","receivedAt":"2007-12-24T14:31:07Z","isPatch":true,"sender":{"key":"bernt@norang.ca","avatar":null},"body":"git rebase --interactive formats the combined commit log message\nincorrectly when squashing 3 or more commits which have no newline on\nthe last line of the commit message.\n\nSigned-off-by: Bernt Hansen \n---\n\nThis may well be the wrong fix for this problem but my attempts to make\ngit-rebase--interactive.sh append a newline breaks too many tests in the\ntest suite.\n\nI tried something like this in git-rebase--interactive.sh:\n\n- git cat-file commit HEAD | sed -e '1,/^$/d'\n+ git cat-file commit HEAD | sed -e '1,/^$/d' -e '$a\\'\n\nSorry I don't have an automated test for git-gui. Are there any?\n\n git-gui/lib/commit.tcl | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl\nindex b2d2d53..1c0586c 100644\n--- a/git-gui/lib/commit.tcl\n+++ b/git-gui/lib/commit.tcl\n@@ -303,7 +303,7 @@ A rescan will be automatically started now.\n \t\tputs stderr [mc \"warning: Tcl does not support encoding '%s'.\" $enc]\n \t\tfconfigure $msg_wt -encoding utf-8\n \t}\n-\tputs -nonewline $msg_wt $msg\n+\tputs $msg_wt $msg\n \tclose $msg_wt\n \n \t# -- Create the commit.\n-- \n1.5.4.rc1.22.g88b9\n"},{"id":"64079","messageId":"Pine.LNX.4.64.0712241835210.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11364","inReplyTo":"8763yof9lg.fsf@gollum.intra.norang.ca","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-24T17:38:48Z","receivedAt":"2007-12-24T17:38:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 24 Dec 2007, Bernt Hansen wrote:\n\n> git rebase --interactive formats the combined commit log message \n> incorrectly when squashing 3 or more commits which have no newline on \n> the last line of the commit message.\n\nThis is a patch for git-gui, so why not make that clear in the subject? \n(And I have a hunch that Shawn would have liked the patch relative to \ngit-gui.git, not git.git...)\n\nFurther, there are other tools than rebase -i that like commit messages \nbetter when terminated by a newline, and _that_ is what I would like to \nread in the commit message for this patch.\n\nIf nobody is quicker, I'll try to fix the problem on the rebase -i side in \na few days.\n\nThanks,\nDscho\n"},{"id":"64085","messageId":"20071225044202.GO14735@spearce.org","threadId":"11364","inReplyTo":"Pine.LNX.4.64.0712241835210.14355@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-25T04:42:02Z","receivedAt":"2007-12-25T04:42:02Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Mon, 24 Dec 2007, Bernt Hansen wrote:\n> \n> > git rebase --interactive formats the combined commit log message \n> > incorrectly when squashing 3 or more commits which have no newline on \n> > the last line of the commit message.\n> \n> This is a patch for git-gui, so why not make that clear in the subject? \n> (And I have a hunch that Shawn would have liked the patch relative to \n> git-gui.git, not git.git...)\n\nIndeed.\n\nMost git-gui changes have a subject that starts with \"git-gui:\" so\nits clear in both the email and in the commit log that the change is\na git-gui change. Remember, git-gui's logs show up in the core Git\nlogs (as its merged with -s subtree) so having that git-gui: prefix\ndoes help people to localize the change within the overall suite.\n\ngit-am -3 does a reasonable job at correcting patches that are like\nthis one is (that aren't relative to git-gui.git) so that's less\nof an issue for me. And what git-am -3 cannot correct git-apply\n-p2 usually does. If that can't fix the patch then I'll usually\nthrow it back as its then most likely a true conflict.\n \n> Further, there are other tools than rebase -i that like commit messages \n> better when terminated by a newline, and _that_ is what I would like to \n> read in the commit message for this patch.\n\nHmmph. For that reason alone I'm tempted to *not* apply Bernt's\npatch.\n\nThere is nothing that requires that a commit object end with an LF.\nSo tools that make this assumption (that there is a trailing LF)\nwhile processing the body of a commit message are quite simply\nbroken.\n\nIts easy in fast-import to generate commits without a trailing LF.\nOr in many text editors its possible to save a file with no trailing\nLF on the last line. My favorite VI clone does that; if the file\ndoesn't end with an LF when it opens its *damned* hard to get a\ntrailing LF onto that last line. And yes, that's the editor I use\nfor commit messages when I'm not using git-gui.\n\nIMHO git-gui is producing valid commit messages, and always does\nso with no trailing LF, and any tool that is assuming a trailing\nLF is always present is broken.\n\nKeeping git-gui behavior like this actually highlights the other\ntools that are broken (here Bernt found git-rebase--interactive).\n\n\nI'd like to hear Junio's or Linus' two cents on the matter, but\nif we really want to say that all commits must end with an LF then\nmaybe git-commit-tree, git-hash-object and git-fast-import should be\nperforming that sort of validation before creating such an object in\nthe ODB. Which is probably a change that shouldn't be made before\n1.6.0 as its somewhat likely to break people's existing scripts.\n\n-- \nShawn.\n"},{"id":"64086","messageId":"20071225044600.GP14735@spearce.org","threadId":"11364","inReplyTo":"8763yof9lg.fsf@gollum.intra.norang.ca","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-25T04:46:00Z","receivedAt":"2007-12-25T04:46:00Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"[... comments for patch in reply to Dscho's reply...]\n\nBernt Hansen wrote:\n> Sorry I don't have an automated test for git-gui. Are there any?\n\nNo. I didn't really build git-gui very well for that sort of thing.\nPart of my long-term plan for git-gui is to do refactoring on it\nso that we can create automated tests for the lower level parts\n(the logic behind the GUI). Then we can actually do some automated\ntesting.\n\nWow. I just realized git-gui is almost 14 months old. Its probably\ngoing to be another year before the above said refactoring is\ncompletely finished, but its something that needs to be done if\ngit-gui is going to survive its terrible twos.\n\n-- \nShawn.\n"},{"id":"64090","messageId":"7v4pe7p176.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"20071225044202.GO14735@spearce.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-25T09:34:37Z","receivedAt":"2007-12-25T09:34:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> I'd like to hear Junio's or Linus' two cents on the matter, but\n> if we really want to say that all commits must end with an LF then\n> maybe git-commit-tree, git-hash-object and git-fast-import should be\n> performing that sort of validation before creating such an object in\n> the ODB.\n\nI've so far tried to keep the lowest-level plumbing commit-tree\n(and even lower hash-object) without such an artificial limit.\nAt the lowest level, commit objects should be able to hold any\nbyte sequence (this includes NUL bytes) as the user wishes.\nPeople who want to use git to implement/experiment a data\nstructure that may not have anything to do with the usual SCM\nshould be able to do so using such low-level.\n\nIt is a different story about what conventions should Porcelains\nenforce. For example, I'd be perfectly happy if git-commit (at\nleast under its default mode of operation) does not allow NULs\nnor incomplete lines in the message, and if git-format-patch and\ngit-am do not to pass something you cannot e-mail sanely (but\nthat is only true once we rewrite rebase not to rely on the\npipeline between them). Porcelain level should really make it\neasy and safe for the users to work with git as an SCM.\n"},{"id":"64103","messageId":"87myrxqrev.fsf@gollum.intra.norang.ca","threadId":"11364","inReplyTo":"20071225044202.GO14735@spearce.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Bernt Hansen","fromEmail":"bernt@alumni.uwaterloo.ca","sentAt":"2007-12-26T17:47:36Z","receivedAt":"2007-12-26T17:47:36Z","isPatch":true,"sender":{"key":"bernt@norang.ca","avatar":null},"body":"\"Shawn O. Pearce\" writes:\n\n> Johannes Schindelin wrote:\n>> This is a patch for git-gui, so why not make that clear in the subject? \n>> (And I have a hunch that Shawn would have liked the patch relative to \n>> git-gui.git, not git.git...)\n>\n> Indeed.\n>\n> its clear in both the email and in the commit log that the change is\n> a git-gui change. Remember, git-gui's logs show up in the core Git\n> logs (as its merged with -s subtree) so having that git-gui: prefix\n> does help people to localize the change within the overall suite.\n>\n\nThanks for the feedback on the patch.\n\nThis is my first attempt at creating a patch for git (even if it is\nmostly trivial in this case) and I wasn't aware of the git-gui.gitk repo\nand conventions regarding the commit message. I just tried to follow\nwhat was in Documentation/SubmittingPatches. I'll try to do better next\ntime :)\n\n>> Further, there are other tools than rebase -i that like commit messages \n>> better when terminated by a newline, and _that_ is what I would like to \n>> read in the commit message for this patch.\n>\n> Hmmph. For that reason alone I'm tempted to *not* apply Bernt's\n> patch.\n>\n> There is nothing that requires that a commit object end with an LF.\n> So tools that make this assumption (that there is a trailing LF)\n> while processing the body of a commit message are quite simply\n> broken.\n\nForcing a LF on the end of the commit message feels wrong to me too.\n\nThis band-aid solution fixes the issue I'm dealing with for\ngit-rebase -i when squashing 3 or more commits created by git-gui.\n\nI agree with Sean and think the more correct fix would be to make\ngit rebase -i and any other tools we encounter with similar problems\nhandle the case where there is no newline at the end of the commit\nmessage.\n\nThe patch as it stands should probably not be applied.\n\n-Bernt\n"},{"id":"64104","messageId":"7v4pe5nt8m.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"20071225044202.GO14735@spearce.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-26T19:36:25Z","receivedAt":"2007-12-26T19:36:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> There is nothing that requires that a commit object end with an LF.\n> So tools that make this assumption (that there is a trailing LF)\n> while processing the body of a commit message are quite simply\n> broken.\n> ...\n> IMHO git-gui is producing valid commit messages, and always does\n> so with no trailing LF, and any tool that is assuming a trailing\n> LF is always present is broken.\n\nI would not go that far, even though I would agree that the\nconsumers of existing commits should be lenient and the creators\nof new commits should be strict.\n\nNow, \"strict\" and \"lenient\" are both relative to some yardstick,\nbut relative to what? I would say that the UI layer of \"git the\nSCM\" is about helping humans create commit messages for human\nconsumption, even though the low-level commit objects are\nequipped to record any binary blob (including NUL byte).\n\nAs UI layer programs, I think \"git commit\" and \"git rebase -i\"\ncan and should be stricter than allowing \"arbitrary binary\nblobs\". Namely, they should make sure what they produce are\ngood text messages (and a good text message ends with a LF ---\nprepare a file with an incomplete line, run \"cat file\" from\ninteractive shell on it, and see your prompt tucked at the end\nbefore arguing otherwise).\n\nSo how about doing something like this?\n\n---\n git-rebase--interactive.sh | 6 ++++--\n 1 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 090c3e5..d0d83c3 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -215,15 +215,17 @@ make_squash_message () {\n \t\tCOUNT=$(($(sed -n \"s/^# This is [^0-9]*\\([1-9][0-9]*\\).*/\\1/p\" \\\n \t\t\t< \"$SQUASH_MSG\" | tail -n 1)+1))\n \t\techo \"# This is a combination of $COUNT commits.\"\n-\t\tsed -n \"2,\\$p\" < \"$SQUASH_MSG\"\n+\t\tsed -e 1d -e '2,/^./{\n+\t\t\t/^$/d\n+\t\t}' <\"$SQUASH_MSG\"\n \telse\n \t\tCOUNT=2\n \t\techo \"# This is a combination of two commits.\"\n \t\techo \"# The first commit's message is:\"\n \t\techo\n \t\tgit cat-file commit HEAD | sed -e '1,/^$/d'\n-\t\techo\n \tfi\n+\techo\n \techo \"# This is the $(nth_string $COUNT) commit message:\"\n \techo\n \tgit cat-file commit $1 | sed -e '1,/^$/d'\n"},{"id":"64110","messageId":"7vr6h9m2zb.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"7vy7bppv3s.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-26T23:48:56Z","receivedAt":"2007-12-26T23:48:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Will do, but the code looks quite bad (not entirely your fault).\n>\n> Line by line comment to show my puzzlement.\n>\n> \t\t# commit if necessary\n>\n> Ok, the user has prepared the index for us, and we are going to do some\n> tests and conditionally create commit.\n>\n> \t\tgit rev-parse --verify HEAD > /dev/null &&\n>\n> Do we have HEAD commit? Why check this --- we do not want to rebase\n> from the beginning of time? No, that's not it. If this fails, there is\n> something seriously wrong. This is not about \"will we make a commit?\"\n> check at all. This is a basic sanity check and if it fails we must\n> abort, not just skip.\n>\n> \t\tgit update-index --refresh &&\n> \t\tgit diff-files --quiet &&\n>\n> Is the work tree clean with respect to the index? Why check this --- we\n> want to skip the commit if work tree is dirty? Or is this trying to\n> enforce the invariant that during the rebase the work tree and index and\n> HEAD should all match? If the latter, failure from this again is a\n> reason to abort.\n>\n> \t\t! git diff-index --cached --quiet HEAD -- &&\n>\n> Do we have something to commit? This needs to be checked so that we can\n> skip a commit that results in emptyness, so using this as a check to see\n> if we should commit makes sense.\n>\n> \t\t. \"$DOTEST\"/author-script && {\n> \t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n> \t\t} &&\n>\n> Find GIT_AUTHOR_* variables and if we are amending rewind the HEAD. The\n> failure from this is a grave problem and reason to abort, isn't it?\n>\n> \t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> \t\tgit commit --no-verify -F \"$DOTEST\"/message -e\n>\n> Then we go on to create commit. As you said, failure from this is a\n> grave error.\n\nAny response to this or problems in the clean-up patch?\n\n> ---\n> git-rebase--interactive.sh | 29 +++++++++++++++++++----------\n> 1 files changed, 19 insertions(+), 10 deletions(-)\n>\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index 090c3e5..7aa4278 100755\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -363,17 +363,26 @@ do\n> \n> \t\ttest -d \"$DOTEST\" || die \"No interactive rebase running\"\n> \n> -\t\t# commit if necessary\n> -\t\tgit rev-parse --verify HEAD > /dev/null &&\n> -\t\tgit update-index --refresh &&\n> -\t\tgit diff-files --quiet &&\n> -\t\t! git diff-index --cached --quiet HEAD -- &&\n> -\t\t. \"$DOTEST\"/author-script && {\n> -\t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n> -\t\t} &&\n> -\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> -\t\tif ! git commit --no-verify -F \"$DOTEST\"/message -e\n> +\t\t# Sanity check\n> +\t\tgit rev-parse --verify HEAD >/dev/null ||\n> +\t\t\tdie \"Cannot read HEAD\"\n> +\t\tgit update-index --refresh && git diff-files --quiet ||\n> +\t\t\tdie \"Working tree is dirty\"\n> +\n> +\t\t# do we have anything to commit?\n> +\t\tif git diff-index --cached --quiet HEAD --\n> \t\tthen\n> +\t\t\t: Nothing to commit -- skip this\n> +\t\telse\n> +\t\t\t. \"$DOTEST\"/author-script ||\n> +\t\t\t\tdie \"Cannot find the author identity\"\n> +\t\t\tif test -f \"$DOTEST\"/amend\n> +\t\t\tthen\n> +\t\t\t\tgit reset --soft HEAD^ ||\n> +\t\t\t\tdie \"Cannot rewind the HEAD\"\n> +\t\t\tfi\n> +\t\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> +\t\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n> \t\t\tdie \"Could not commit staged changes.\"\n> \t\tfi\n> \n"},{"id":"64117","messageId":"20071227041902.GR14735@spearce.org","threadId":"11364","inReplyTo":"87myrxqrev.fsf@gollum.intra.norang.ca","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-27T04:19:02Z","receivedAt":"2007-12-27T04:19:02Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Bernt Hansen wrote:\n> \"Shawn O. Pearce\" writes:\n> >\n> > its clear in both the email and in the commit log that the change is\n> > a git-gui change. Remember, git-gui's logs show up in the core Git\n> > logs (as its merged with -s subtree) so having that git-gui: prefix\n> > does help people to localize the change within the overall suite.\n> \n> This is my first attempt at creating a patch for git (even if it is\n> mostly trivial in this case) and I wasn't aware of the git-gui.gitk repo\n> and conventions regarding the commit message. I just tried to follow\n> what was in Documentation/SubmittingPatches. I'll try to do better next\n> time :)\n\nIts a good first attempt. I also just sent a patch to Junio to try\nand make this \"special case\" of directing git-gui changes to me more\nclear for new folk.\n \n> Forcing a LF on the end of the commit message feels wrong to me too.\n\nI think Junio just convinced me otherwise.\n\nWe probably should change git-gui to always end the last line of\nthe message with an LF. To be honest I'm not really sure why it\ndoesn't do that now. ;-)\n \n> The patch as it stands should probably not be applied.\n\nBut I think that is now only because the commit message could be\nclarified to state that its for git-gui (e.g. start with \"git-gui:\")\nand probably shouldn't be so specific to rebase -i's breakage but\ninstead talk about how its good to be strict in what you create,\nand lenient in what you accept, and since we're creating here,\nwe should always try to Do The Right Thing(tm).\n\nIf you respin the patch with a more descriptive message I'll put\nit into 0.9.1.\n\n-- \nShawn.\n"},{"id":"64135","messageId":"87k5mzmun7.fsf_-_@gollum.intra.norang.ca","threadId":"11364","inReplyTo":"20071227041902.GR14735@spearce.org","subject":"[PATCH] git-gui: Make commit log messages end with a newline","fromName":"Bernt Hansen","fromEmail":"bernt@norang.ca","sentAt":"2007-12-28T02:15:56Z","receivedAt":"2007-12-28T02:15:56Z","isPatch":true,"sender":{"key":"bernt@norang.ca","avatar":null},"body":"Concatenating commit log messages from multiple commits works better\nwhen all of the commits end with a clean line break.\n\nIts good to be strict in what you create, and lenient in what you\naccept, and since we're creating here, we should always try to\nDo The Right Thing(tm).\n\nSigned-off-by: Bernt Hansen \n---\n lib/commit.tcl | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/lib/commit.tcl b/lib/commit.tcl\nindex b2d2d53..1c0586c 100644\n--- a/lib/commit.tcl\n+++ b/lib/commit.tcl\n@@ -303,7 +303,7 @@ A rescan will be automatically started now.\n \t\tputs stderr [mc \"warning: Tcl does not support encoding '%s'.\" $enc]\n \t\tfconfigure $msg_wt -encoding utf-8\n \t}\n-\tputs -nonewline $msg_wt $msg\n+\tputs $msg_wt $msg\n \tclose $msg_wt\n \n \t# -- Create the commit.\n-- \n1.5.4.rc1.21.g0e545\n"},{"id":"64173","messageId":"Pine.LNX.4.64.0712291418360.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11364","inReplyTo":"7vr6h9m2zb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-29T13:26:28Z","receivedAt":"2007-12-29T13:26:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 26 Dec 2007, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > \t\t# commit if necessary\n> >\n> > Ok, the user has prepared the index for us, and we are going to do some\n> > tests and conditionally create commit.\n> >\n> > \t\tgit rev-parse --verify HEAD > /dev/null &&\n> >\n> > Do we have HEAD commit? Why check this --- we do not want to rebase\n> > from the beginning of time? No, that's not it. If this fails, there is\n> > something seriously wrong. This is not about \"will we make a commit?\"\n> > check at all. This is a basic sanity check and if it fails we must\n> > abort, not just skip.\n\nRight. My intention was to have a \"|| die\" at the end of the && cascade.\n\n> >\n> > \t\tgit update-index --refresh &&\n> > \t\tgit diff-files --quiet &&\n> >\n> > Is the work tree clean with respect to the index? Why check this --- we\n> > want to skip the commit if work tree is dirty? Or is this trying to\n> > enforce the invariant that during the rebase the work tree and index and\n> > HEAD should all match? If the latter, failure from this again is a\n> > reason to abort.\n\nExactly. I wanted to make sure that the working directory is not \ndifferent from what is in the index.\n\n> > \t\t! git diff-index --cached --quiet HEAD -- &&\n> >\n> > Do we have something to commit? This needs to be checked so that we can\n> > skip a commit that results in emptyness, so using this as a check to see\n> > if we should commit makes sense.\n> >\n> > \t\t. \"$DOTEST\"/author-script && {\n> > \t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n> > \t\t} &&\n> >\n> > Find GIT_AUTHOR_* variables and if we are amending rewind the HEAD. The\n> > failure from this is a grave problem and reason to abort, isn't it?\n> >\n> > \t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> > \t\tgit commit --no-verify -F \"$DOTEST\"/message -e\n> >\n> > Then we go on to create commit. As you said, failure from this is a\n> > grave error.\n> \n> Any response to this or problems in the clean-up patch?\n> \n> > ---\n> > git-rebase--interactive.sh | 29 +++++++++++++++++++----------\n> > 1 files changed, 19 insertions(+), 10 deletions(-)\n> >\n> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> > index 090c3e5..7aa4278 100755\n> > --- a/git-rebase--interactive.sh\n> > +++ b/git-rebase--interactive.sh\n> > @@ -363,17 +363,26 @@ do\n> > \n> > \t\ttest -d \"$DOTEST\" || die \"No interactive rebase running\"\n> > \n> > -\t\t# commit if necessary\n> > -\t\tgit rev-parse --verify HEAD > /dev/null &&\n> > -\t\tgit update-index --refresh &&\n> > -\t\tgit diff-files --quiet &&\n> > -\t\t! git diff-index --cached --quiet HEAD -- &&\n> > -\t\t. \"$DOTEST\"/author-script && {\n> > -\t\t\ttest ! -f \"$DOTEST\"/amend || git reset --soft HEAD^\n> > -\t\t} &&\n> > -\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> > -\t\tif ! git commit --no-verify -F \"$DOTEST\"/message -e\n> > +\t\t# Sanity check\n> > +\t\tgit rev-parse --verify HEAD >/dev/null ||\n> > +\t\t\tdie \"Cannot read HEAD\"\n> > +\t\tgit update-index --refresh && git diff-files --quiet ||\n> > +\t\t\tdie \"Working tree is dirty\"\n> > +\n> > +\t\t# do we have anything to commit?\n> > +\t\tif git diff-index --cached --quiet HEAD --\n> > \t\tthen\n> > +\t\t\t: Nothing to commit -- skip this\n> > +\t\telse\n> > +\t\t\t. \"$DOTEST\"/author-script ||\n> > +\t\t\t\tdie \"Cannot find the author identity\"\n> > +\t\t\tif test -f \"$DOTEST\"/amend\n> > +\t\t\tthen\n> > +\t\t\t\tgit reset --soft HEAD^ ||\n> > +\t\t\t\tdie \"Cannot rewind the HEAD\"\n> > +\t\t\tfi\n> > +\t\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> > +\t\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n> > \t\t\tdie \"Could not commit staged changes.\"\n> > \t\tfi\n\nLooks good to me! And I'm sorry for taking so long to respond.\n\nCiao,\nDscho\n"},{"id":"64174","messageId":"Pine.LNX.4.64.0712291426500.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11364","inReplyTo":"7v4pe5nt8m.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-29T13:31:14Z","receivedAt":"2007-12-29T13:31:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 26 Dec 2007, Junio C Hamano wrote:\n\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index 090c3e5..d0d83c3 100755\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -215,15 +215,17 @@ make_squash_message () {\n> \t\tCOUNT=$(($(sed -n \"s/^# This is [^0-9]*\\([1-9][0-9]*\\).*/\\1/p\" \\\n> \t\t\t< \"$SQUASH_MSG\" | tail -n 1)+1))\n> \t\techo \"# This is a combination of $COUNT commits.\"\n> -\t\tsed -n \"2,\\$p\" < \"$SQUASH_MSG\"\n> +\t\tsed -e 1d -e '2,/^./{\n> +\t\t\t/^$/d\n> +\t\t}' <\"$SQUASH_MSG\"\n\nIf I read this correctly (haven't tested), then _all_ empty lines are \nremoved from the SQUASH_MSG, right? This is not what I want.\n\nI had something like this in mind, rather:\n\n\t\t-e '\\$s/\\n*$/\\n/'\n\nThis is completely untested, but should show the idea. However, the same \nmust go into this clause:\n\n> \telse\n> \t\tCOUNT=2\n> \t\techo \"# This is a combination of two commits.\"\n> \t\techo \"# The first commit's message is:\"\n> \t\techo\n> \t\tgit cat-file commit HEAD | sed -e '1,/^$/d'\n\nUnfortunately, I am unable to provide a proper patch with proper testing \nright now, since my family threatens me with physical violence, should I \nnot leave the keyboard right n.. OUCH!\n"},{"id":"64199","messageId":"7vodc99gpy.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"Pine.LNX.4.64.0712291426500.14355@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-30T00:19:37Z","receivedAt":"2007-12-30T00:19:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> \t\techo \"# This is a combination of $COUNT commits.\"\n>> -\t\tsed -n \"2,\\$p\" < \"$SQUASH_MSG\"\n>> +\t\tsed -e 1d -e '2,/^./{\n>> +\t\t\t/^$/d\n>> +\t\t}' <\"$SQUASH_MSG\"\n>\n> If I read this correctly (haven't tested), then _all_ empty lines are \n> removed from the SQUASH_MSG, right? This is not what I want.\n\nThat is no what I wanted either.\n\n\"1d\" removes the \"# This is a combination of <$n> commits.\" from\nthe previous round, \"2,/^./{ ... }\" says apply what's in {} to\nlines from second line to the first non-empty line, and what's\nin {} is to remove empty ones.\n\n> Unfortunately, I am unable to provide a proper patch with proper testing \n> right now,...\n\nThat's Ok. Seeing what the patch already in front of you does\nwould be less time consuming.\n"},{"id":"64202","messageId":"Pine.LNX.4.64.0712301124510.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11364","inReplyTo":"7vodc99gpy.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-30T10:26:49Z","receivedAt":"2007-12-30T10:26:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 29 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> \t\techo \"# This is a combination of $COUNT commits.\"\n> >> -\t\tsed -n \"2,\\$p\" < \"$SQUASH_MSG\"\n> >> +\t\tsed -e 1d -e '2,/^./{\n> >> +\t\t\t/^$/d\n> >> +\t\t}' <\"$SQUASH_MSG\"\n> >\n> > If I read this correctly (haven't tested), then _all_ empty lines are \n> > removed from the SQUASH_MSG, right? This is not what I want.\n> \n> That is no what I wanted either.\n> \n> \"1d\" removes the \"# This is a combination of <$n> commits.\" from\n> the previous round, \"2,/^./{ ... }\" says apply what's in {} to\n> lines from second line to the first non-empty line, and what's\n> in {} is to remove empty ones.\n\nOkay, so it removes only the empty lines between the first line and the \nnext non-empty line.\n\nBut if I understood the OP correctly, the problem was a missing newline at \nthe end of the commit message, no?\n\nThanks,\nDscho\n"},{"id":"64207","messageId":"7v63yga20u.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"Pine.LNX.4.64.0712301124510.14355@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-30T10:51:45Z","receivedAt":"2007-12-30T10:51:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> But if I understood the OP correctly, the problem was a missing newline at \n> the end of the commit message, no?\n\nThat's why the \"echo\" was moved out of the conditional, to make\nsure \"# This is the $(nth)\" begins on a fresh line.\n"},{"id":"64210","messageId":"Pine.LNX.4.64.0712301201570.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11364","inReplyTo":"7v63yga20u.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-30T11:03:28Z","receivedAt":"2007-12-30T11:03:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 30 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > But if I understood the OP correctly, the problem was a missing \n> > newline at the end of the commit message, no?\n> \n> That's why the \"echo\" was moved out of the conditional, to make sure \"# \n> This is the $(nth)\" begins on a fresh line.\n\nNot that I care too deeply, but does that not add a newline regardless \nwhether it is needed or not?\n\nThanks,\nDscho\n"},{"id":"64214","messageId":"7vprwo8kzd.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"Pine.LNX.4.64.0712301201570.14355@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-30T11:45:10Z","receivedAt":"2007-12-30T11:45:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Not that I care too deeply, but does that not add a newline regardless \n> whether it is needed or not?\n\nHeh, I can see that you do not care---the original did not even\nadd a newline when necessary (and that is why we have this\nthread). Instead you were adding a newline regardless to the\nend of the first commit, but not doing so for the other ones.\n\nThe patch just moves that unconditional \"echo\"; instead of\nadding one to the end of the first commit (and only the first\none), it adds before the new commit's title message.\n"},{"id":"64215","messageId":"200712301158.lBUBwT3r004608@mi1.bluebottle.com","threadId":"11364","inReplyTo":"7vprwo8kzd.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2007-12-30T11:57:49Z","receivedAt":"2007-12-30T11:57:49Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano :\n\n> Johannes Schindelin writes:\n>\n>> Not that I care too deeply, but does that not add a newline regardless \n>> whether it is needed or not?\n>\n> Heh, I can see that you do not care---the original did not even\n> add a newline when necessary (and that is why we have this\n> thread). Instead you were adding a newline regardless to the\n> end of the first commit, but not doing so for the other ones.\n\nAren't you being too harsh on Johannes these days?\n\nEverybody knows that you are capable of rewriting that part in Perl or Python yourself to fix the issue.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nGet a free email address with REAL anti-spam protection.\nhttp://www.bluebottle.com/tag/1\n"},{"id":"64216","messageId":"7vd4so8k18.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"7vprwo8kzd.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-30T12:05:39Z","receivedAt":"2007-12-30T12:05:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> ... Instead you were adding a newline regardless to the\n> end of the first commit, but not doing so for the other ones.\n\nTo illustrate, this is what I get when trying to squash four\ncommits:\n\n # This is a combination of 4 commits.\n # The first commit's message is:\n\n Documentation/git-submodule.txt: typofix\n\n Signed-off-by: Junio C Hamano \n\n # This is the 2nd commit message:\n\n git-sh-setup: document git_editor() and get_author_ident_from_commit()\n\n These 2 functions were missing from the manpage.\n\n Signed-off-by: Miklos Vajna \n Signed-off-by: Junio C Hamano \n # This is the 3rd commit message:\n\n \"git pull --tags\": error out with a better message.\n\n When \"git pull --tags\" is run without any other arguments, the\n ...\n\nNotice that there is a gap before \"# This is the 2nd commit\" but\nthere isn't any gap before \"# This is the 3rd commit\"?\n\nThe patch under discussion happens to fix this inconsistency as\na side effect.\n"},{"id":"64217","messageId":"7v8x3c8jay.fsf@gitster.siamese.dyndns.org","threadId":"11364","inReplyTo":"200712301158.lBUBwT3r004608@mi1.bluebottle.com","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-30T12:21:25Z","receivedAt":"2007-12-30T12:21:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"しらいしななこ writes:\n\n>> Heh, I can see that you do not care---the original did not even\n>> add a newline when necessary (and that is why we have this\n>> thread). Instead you were adding a newline regardless to the\n>> end of the first commit, but not doing so for the other ones.\n>\n> Aren't you being too harsh on Johannes these days?\n\nNot on purpose, but perhaps I might have been.\n\n> Everybody knows that you are capable of rewriting that part in Perl or Python yourself to fix the issue.\n\nI actually have been trying to avoid Perl (let alone Python nor\nRuby) as \"rebase -i\" is primarily Johannes's bailiwick, and I\nhad an impression that he avoided them for Windows portability.\n\nUnfortunately, sed does not handle incomplete lines well, at\nleast portably. POSIX says very little about it, except that\nits input shall be \"text files\" (i.e. no NUL is allowed, each\nline separated with and with less than {LINE_MAX}\nbytes in length), and its default operation shall read each line\nless its terminating and after manipulation spit it\nout and immediately follow it with a . But a popular\nimplementation (e.g. GNU) actually does not follow the output\nwith a if the input was incomplete line [*1*]\n\n[Footnote]\n\n*1* Otherwise, this would have been a way to add a\nmissing newline to a file that could end with an incomplete\nline:\n\n $ sed -e '' <$file_that_may_end_with_an_incomplete_line\n"},{"id":"64227","messageId":"Pine.LNX.4.64.0712301648300.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11364","inReplyTo":"7vprwo8kzd.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Force new line at end of commit message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-30T15:50:17Z","receivedAt":"2007-12-30T15:50:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[Bernt, your mail filter is less than intelligent and rejects my mails.]\n\nOn Sun, 30 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Not that I care too deeply, but does that not add a newline regardless \n> > whether it is needed or not?\n> \n> Heh, I can see that you do not care---the original did not even\n> add a newline when necessary (and that is why we have this\n> thread).\n\nUmm. It was on purpose, since I found the empty lines between the commit \nmessages and the comment more pleasing than no empty space.\n\n> The patch just moves that unconditional \"echo\"; instead of adding one to \n> the end of the first commit (and only the first one), it adds before the \n> new commit's title message.\n\nWell, ACK from me, then.\n\nCiao,\nDscho\n"}]}