{"thread":{"id":"39162","subject":"Bug report : bad filter-branch (OSX only)","startedAt":"2015-04-26T09:25:52Z","lastAt":"2015-04-29T18:17:30Z","messageCount":12,"participants":["Olivier ROLAND","Jeff King","Junio C Hamano","Roberto Tyley","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"260033","messageId":"CAM=W1NkZr6o-DCxXskeWC8xjRMiT2P9qXeeUe91qLBqOxzqNtg@mail.gmail.com","threadId":"39162","inReplyTo":null,"subject":"Bug report : bad filter-branch (OSX only)","fromName":"Olivier ROLAND","fromEmail":"cyrus-dev@edla.org","sentAt":"2015-04-26T09:25:52Z","receivedAt":"2015-04-26T09:25:52Z","isPatch":false,"sender":{"key":"cyrus-dev@edla.org","avatar":null},"body":"Hello,\n\nSeem to be a bug.\n\nOSX 10.10.3 git 2.3.6 HFS+ case-sensitive\n\nHow to reproduce :\nStep 1 : git clone https://github.com/begeric/FastParsers.git\nStep 2 : cd FastParsers/\nStep 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -- --all\n\nResult on OSX :\nRewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206)\nRef 'refs/heads/experiment' was rewritten\nRef 'refs/remotes/origin/experiment' was rewritten\nWARNING: Ref 'refs/remotes/origin/experiment' is unchanged\nRef 'refs/remotes/origin/master' was rewritten\n\nResult on Debian :\nRewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206)\nWARNING: Ref 'refs/heads/experiment' is unchanged\nWARNING: Ref 'refs/remotes/origin/experiment' is unchanged\nWARNING: Ref 'refs/remotes/origin/experiment' is unchanged\nWARNING: Ref 'refs/remotes/origin/master' is unchanged\n\nDo you have any thoughts on this ?\n\nThanks.\n"},{"id":"260101","messageId":"20150428055506.GJ24580@peff.net","threadId":"39162","inReplyTo":"CAM=W1NkZr6o-DCxXskeWC8xjRMiT2P9qXeeUe91qLBqOxzqNtg@mail.gmail.com","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-28T05:55:06Z","receivedAt":"2015-04-28T05:55:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 26, 2015 at 11:25:52AM +0200, Olivier ROLAND wrote:\n\n> OSX 10.10.3 git 2.3.6 HFS+ case-sensitive\n> \n> How to reproduce :\n> Step 1 : git clone https://github.com/begeric/FastParsers.git\n> Step 2 : cd FastParsers/\n> Step 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -- --all\n> \n> Result on OSX :\n> Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206)\n> Ref 'refs/heads/experiment' was rewritten\n> Ref 'refs/remotes/origin/experiment' was rewritten\n> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n> Ref 'refs/remotes/origin/master' was rewritten\n> \n> Result on Debian :\n> Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206)\n> WARNING: Ref 'refs/heads/experiment' is unchanged\n> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n> WARNING: Ref 'refs/remotes/origin/master' is unchanged\n> \n> Do you have any thoughts on this ?\n\nWeird. Did you build both versions of git from source (that is, there's\nno question that the OS X one is a hacked-up Apple git or something)?\n\nPresumably it's some incompatibility in the shells used. What does:\n\n  head -1 \"$(git --exec-path)/git-filter-branch\"\n\nsay about the shell in use on each system? Does running that shell with\n\"--version\" report anything useful?\n\n-Peff\n"},{"id":"260122","messageId":"CAM=W1NnR2-T7vpMSM-3-VypnR-T235tMudyjJowtj5utNmoKNQ@mail.gmail.com","threadId":"39162","inReplyTo":"20150428055506.GJ24580@peff.net","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Olivier ROLAND","fromEmail":"cyrus-dev@edla.org","sentAt":"2015-04-28T11:02:17Z","receivedAt":"2015-04-28T11:02:17Z","isPatch":false,"sender":{"key":"cyrus-dev@edla.org","avatar":null},"body":"2015-04-28 7:55 GMT+02:00 Jeff King <peff@peff.net>:\n> On Sun, Apr 26, 2015 at 11:25:52AM +0200, Olivier ROLAND wrote:\n>\n>> OSX 10.10.3 git 2.3.6 HFS+ case-sensitive\n>>\n>> How to reproduce :\n>> Step 1 : git clone https://github.com/begeric/FastParsers.git\n>> Step 2 : cd FastParsers/\n>> Step 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -- --all\n>>\n>> Result on OSX :\n>> Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206)\n>> Ref 'refs/heads/experiment' was rewritten\n>> Ref 'refs/remotes/origin/experiment' was rewritten\n>> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n>> Ref 'refs/remotes/origin/master' was rewritten\n>>\n>> Result on Debian :\n>> Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206)\n>> WARNING: Ref 'refs/heads/experiment' is unchanged\n>> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n>> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n>> WARNING: Ref 'refs/remotes/origin/master' is unchanged\n>>\n>> Do you have any thoughts on this ?\n>\n> Weird. Did you build both versions of git from source (that is, there's\n> no question that the OS X one is a hacked-up Apple git or something)?\n>\n> Presumably it's some incompatibility in the shells used. What does:\n>\n>   head -1 \"$(git --exec-path)/git-filter-branch\"\n>\n> say about the shell in use on each system? Does running that shell with\n> \"--version\" report anything useful?\n>\n> -Peff\n\nHi,\n\nBoth versions are builded from source.\nhead -1 \"$(git --exec-path)/git-filter-branch\"\n#!/bin/sh\n\nsh --version\nGNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14)\nCopyright (C) 2007 Free Software Foundation, Inc.\n\n/bin/bash --version\nGNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)\n\nThe bug seem really git related.\n\nThanks.\n"},{"id":"260157","messageId":"20150429043947.GA10702@peff.net","threadId":"39162","inReplyTo":"CAM=W1NnR2-T7vpMSM-3-VypnR-T235tMudyjJowtj5utNmoKNQ@mail.gmail.com","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-29T04:39:47Z","receivedAt":"2015-04-29T04:39:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 28, 2015 at 01:02:17PM +0200, Olivier ROLAND wrote:\n\n> Both versions are builded from source.\n> head -1 \"$(git --exec-path)/git-filter-branch\"\n> #!/bin/sh\n> \n> sh --version\n> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14)\n> Copyright (C) 2007 Free Software Foundation, Inc.\n> \n> /bin/bash --version\n> GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)\n> \n> The bug seem really git related.\n\nYes, but I guessed it might be part of the filter-branch shell script\nthat behaves differently under two different shells (i.e., that we used\nsome unportable construct). However, I built bash 3.2.57 on my Linux box\nand could not replicate the problem.\n\nThe other \"usual\" thing that causes bugs to show up on OS X but not\nLinux is case-folding. But you said you are using a case-sensitive\nfilesystem, so it's probably not that.\n\nSo I can't figure out how to replicate the problem here.\n\n-Peff\n"},{"id":"260158","messageId":"20150429045600.GA10781@peff.net","threadId":"39162","inReplyTo":"20150429043947.GA10702@peff.net","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-29T04:56:00Z","receivedAt":"2015-04-29T04:56:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 29, 2015 at 12:39:47AM -0400, Jeff King wrote:\n\n> So I can't figure out how to replicate the problem here.\n\nActually, that's not quite true. I could get hold of an OS X system to\nreplicate, which I just did.\n\nThe problem is that commit 3b754f212 does not have a newline at the end\nof its commit message, and the OS X version of sed doesn't preserve\nthat.\n\nHere's a much smaller reproduction recipe:\n\n  git init\n  echo content >file\n  git add file\n  tree=$(git write-tree)\n  commit=$(printf 'no newline' | git commit-tree $tree)\n  git update-ref HEAD $commit\n  git filter-branch\n\nOn my Linux system, this results in an unchanged history, but on OS X,\nthe commit is rewritten to have a newline at the end of the commit\nmessage.\n\nThe culprit is this line from git-filter-branch:\n\n        sed -e '1,/^$/d' <../commit | \\\n                eval \"$filter_msg\" > ../message ||\n                        die \"msg filter failed: $filter_msg\"\n\nThe \"sed\" command silently appends an extra newline to the final line of\nthe message.  You can see the sed behavior more directly with:\n\n  printf foo | sed -ne 1p\n\nwhich adds a newline on OS X, but not when using GNU sed on Linux. It\nlooks like OS X has just BSD sed, so the same behavior probably happens\non FreeBSD and elsewhere.\n\nI'm not sure of a solution short of replacing the use of sed here with\nsomething else. perl would be a simple choice, but filter-branch does\nnot otherwise depend on it. We could use a shell \"read\" loop, but those\nare quite slow (and filter-branch is slow enough as it is!).\n\n-Peff\n"},{"id":"260159","messageId":"xmqqy4lbtrvj.fsf@gitster.dls.corp.google.com","threadId":"39162","inReplyTo":"20150429045600.GA10781@peff.net","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-29T05:39:44Z","receivedAt":"2015-04-29T05:39:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I'm not sure of a solution short of replacing the use of sed here with\n> something else. perl would be a simple choice, but filter-branch does\n> not otherwise depend on it. We could use a shell \"read\" loop, but those\n> are quite slow (and filter-branch is slow enough as it is!).\n\nYou need to only skip the header part, right?\nI would imagine that\n\n(\n\twhile read x && test -n \"$x\"\n        do\n        \t:;\n\tdone\n\tcat\n) <../commit | eval \"$filter_msg\"\n\nwould not spin too much in shell loop, perhaps?\n"},{"id":"260167","messageId":"CAFY1edZ=NjiRsBB6TyiR_as3vtiFHSQthKbnhbNPdKKtYNH2mg@mail.gmail.com","threadId":"39162","inReplyTo":"CAM=W1NkZr6o-DCxXskeWC8xjRMiT2P9qXeeUe91qLBqOxzqNtg@mail.gmail.com","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Roberto Tyley","fromEmail":"roberto.tyley@gmail.com","sentAt":"2015-04-29T14:42:07Z","receivedAt":"2015-04-29T14:42:07Z","isPatch":false,"sender":{"key":"roberto.tyley@gmail.com","avatar":"https://avatars.githubusercontent.com/u/52038?v=4"},"body":"As an aside, if you're a Scala dev\n(https://github.com/begeric/FastParsers is a scala library), you might\nfind it fun to play with https://rtyley.github.io/bfg-repo-cleaner/ -\nyou could probably write some scala (eg a custom BFG\nCommitNodeCleaner) that would do whatever it is you want filter-branch\nto do.\n\nRoberto\n\nOn 26 April 2015 at 10:25, Olivier ROLAND <cyrus-dev@edla.org> wrote:\n> Hello,\n>\n> Seem to be a bug.\n>\n> OSX 10.10.3 git 2.3.6 HFS+ case-sensitive\n>\n> How to reproduce :\n> Step 1 : git clone https://github.com/begeric/FastParsers.git\n> Step 2 : cd FastParsers/\n> Step 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -- --all\n>\n> Result on OSX :\n> Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206)\n> Ref 'refs/heads/experiment' was rewritten\n> Ref 'refs/remotes/origin/experiment' was rewritten\n> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n> Ref 'refs/remotes/origin/master' was rewritten\n>\n> Result on Debian :\n> Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206)\n> WARNING: Ref 'refs/heads/experiment' is unchanged\n> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n> WARNING: Ref 'refs/remotes/origin/experiment' is unchanged\n> WARNING: Ref 'refs/remotes/origin/master' is unchanged\n>\n> Do you have any thoughts on this ?\n>\n> Thanks.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"260178","messageId":"20150429154857.GA13518@peff.net","threadId":"39162","inReplyTo":"xmqqy4lbtrvj.fsf@gitster.dls.corp.google.com","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-29T15:48:58Z","receivedAt":"2015-04-29T15:48:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 28, 2015 at 10:39:44PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > I'm not sure of a solution short of replacing the use of sed here with\n> > something else. perl would be a simple choice, but filter-branch does\n> > not otherwise depend on it. We could use a shell \"read\" loop, but those\n> > are quite slow (and filter-branch is slow enough as it is!).\n> \n> You need to only skip the header part, right?\n> I would imagine that\n> \n> (\n> \twhile read x && test -n \"$x\"\n>         do\n>         \t:;\n> \tdone\n> \tcat\n> ) <../commit | eval \"$filter_msg\"\n> \n> would not spin too much in shell loop, perhaps?\n\nYeah, that is not too bad. Probably we want \"read -r\", just in case of\nweirdness in the header lines (and that's in POSIX, and we use it\nin other scripts, so it should be portable enough). And we can save a\nsubshell if we don't mind the potential variable-name conflict.\n\nHere's what I came up with.\n\n-- >8 --\nSubject: filter-branch: avoid passing commit message through sed\n\nOn some systems (like OS X), if sed encounters input without\na trailing newline, it will silently add it. As a result,\n\"git filter-branch\" on such systems may silently rewrite\ncommit messages that omit a trailing newline. Even though\nthis is not something we generate ourselves with \"git\ncommit\", it's better for filter-branch to preserve the\noriginal data as closely as possible.\n\nWe're using sed here only to strip the header fields from\nthe commit object. We can accomplish the same thing with a\nshell loop. Since shell \"read\" calls are slow (usually one\nsyscall per byte), we use \"cat\" once we've skipped past the\nheader. Depending on the size of your commit messages, this\nis probably faster (you pay the cost to fork, but then read\nthe data in saner-sized chunks). This idea is shamelessly\nstolen from Junio.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nI confirmed the test fixes things on the OS X box I have access to.\n\nThe \"probably faster\" above is of course hand-waving. On my system\nstarting \"cat\" takes only about 40 syscalls, so that would naively imply\nit's a win in for all but the shortest messages. But of course \"fork()\"\nis a much more expensive syscall than \"read()\".\n\n git-filter-branch.sh     | 10 +++++++++-\n t/t7003-filter-branch.sh | 10 ++++++++++\n 2 files changed, 19 insertions(+), 1 deletion(-)\n\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex e6e99f5..5b3f63d 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -346,7 +346,15 @@ while read commit parents; do\n \t\t\t\tdie \"parent filter failed: $filter_parent\"\n \tfi\n \n-\tsed -e '1,/^$/d' <../commit | \\\n+\t{\n+\t\twhile read -r header_line && test -n \"$header_line\"\n+\t\tdo\n+\t\t\t# skip header lines...\n+\t\t\t:;\n+\t\tdone\n+\t\t# and output the actual commit message\n+\t\tcat\n+\t} <../commit |\n \t\teval \"$filter_msg\" > ../message ||\n \t\t\tdie \"msg filter failed: $filter_msg\"\n \tworkdir=$workdir @SHELL_PATH@ -c \"$filter_commit\" \"git commit-tree\" \\\ndiff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh\nindex 66643e4..855afda 100755\n--- a/t/t7003-filter-branch.sh\n+++ b/t/t7003-filter-branch.sh\n@@ -394,4 +394,14 @@ test_expect_success 'replace submodule revision' '\n \ttest $orig_head != `git show-ref --hash --head HEAD`\n '\n \n+test_expect_success 'filter commit message without trailing newline' '\n+\tgit reset --hard original &&\n+\tcommit=$(printf \"no newline\" | git commit-tree HEAD^{tree}) &&\n+\tgit update-ref refs/heads/no-newline $commit &&\n+\tgit filter-branch -f refs/heads/no-newline &&\n+\techo $commit >expect &&\n+\tgit rev-parse refs/heads/no-newline >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n-- \n2.4.0.rc3.477.gc25258d\n"},{"id":"260183","messageId":"xmqqioce6gon.fsf@gitster.dls.corp.google.com","threadId":"39162","inReplyTo":"20150429154857.GA13518@peff.net","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-29T16:30:00Z","receivedAt":"2015-04-29T16:30:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Apr 28, 2015 at 10:39:44PM -0700, Junio C Hamano wrote:\n>\n>> Jeff King <peff@peff.net> writes:\n>> \n>> > I'm not sure of a solution short of replacing the use of sed here with\n>> > something else. perl would be a simple choice, but filter-branch does\n>> > not otherwise depend on it. We could use a shell \"read\" loop, but those\n>> > are quite slow (and filter-branch is slow enough as it is!).\n>> \n>> You need to only skip the header part, right?\n>> I would imagine that\n>> \n>> (\n>> \twhile read x && test -n \"$x\"\n>>         do\n>>         \t:;\n>> \tdone\n>> \tcat\n>> ) <../commit | eval \"$filter_msg\"\n>> \n>> would not spin too much in shell loop, perhaps?\n>\n> Yeah, that is not too bad. Probably we want \"read -r\", just in case of\n> weirdness in the header lines (and that's in POSIX, and we use it\n> in other scripts, so it should be portable enough). And we can save a\n> subshell if we don't mind the potential variable-name conflict.\n\nAs all we care about is \"have we hit an empty line\", I do not think \"-r\"\nreally matters, but it would not hurt.\n\nAs to s/()/{}/, please tell me what I am doing wrong.  I am getting\nthe same process IDs from all of the $$s and the only difference\nseems to be variable clobbering.\n\n-- >8 --\n#!/bin/sh\n\ncat >/var/tmp/tester <<EOF || exit\na\nb\n\nc\nd\nEOF\n\n\nx=foo\necho \"My id is $$\"\n(\n\techo \"inside paren $$\"\n\twhile read x && test -n \"$x\"\n\tdo\n\t\t:;\n\tdone\n\tcat\n) </var/tmp/tester\necho \"x=<$x>\"\n\nx=foo\n{\n\techo \"inside brace $$\"\n\twhile read x && test -n \"$x\"\n\tdo\n\t\t:;\n\tdone\n\tcat\n} </var/tmp/tester\necho \"x=<$x>\"\n"},{"id":"260184","messageId":"20150429164315.GA26682@peff.net","threadId":"39162","inReplyTo":"xmqqioce6gon.fsf@gitster.dls.corp.google.com","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-29T16:43:15Z","receivedAt":"2015-04-29T16:43:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 29, 2015 at 09:30:00AM -0700, Junio C Hamano wrote:\n\n> >> (\n> >> \twhile read x && test -n \"$x\"\n> >>         do\n> >>         \t:;\n> >> \tdone\n> >> \tcat\n> >> ) <../commit | eval \"$filter_msg\"\n> >> \n> >> would not spin too much in shell loop, perhaps?\n> >\n> > Yeah, that is not too bad. Probably we want \"read -r\", just in case of\n> > weirdness in the header lines (and that's in POSIX, and we use it\n> > in other scripts, so it should be portable enough). And we can save a\n> > subshell if we don't mind the potential variable-name conflict.\n> \n> As all we care about is \"have we hit an empty line\", I do not think \"-r\"\n> really matters, but it would not hurt.\n\nI think something like:\n\n  author ...\n  committer ...\n  encoding foo\\\n\n  this is the real commit message\n\nwould behave incorrectly without \"-r\". I would be shocked if that ever\nhappens in real life, but I think it doesn't hurt to be careful.\n\n> As to s/()/{}/, please tell me what I am doing wrong.  I am getting\n> the same process IDs from all of the $$s and the only difference\n> seems to be variable clobbering.\n\n$$ is always the pid of the main shell process, even in a subshell. If\nyour shell is bash, it provides $BASHPID which can tell the difference\n(if you put $BASHPID in your test script, it does show that we fork for\nthe subshell).\n\nOn Linux, you can also test with \"strace -fce clone\". Interestingly,\ndash produces one fewer fork than bash on your test script, but I didn't\ntrack down the exact difference. But I can imagine a shell that is smart\nenough to realize a fork is not required in this instance.\n\n-Peff\n"},{"id":"260185","messageId":"xmqqegn26eot.fsf@gitster.dls.corp.google.com","threadId":"39162","inReplyTo":"20150429164315.GA26682@peff.net","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-29T17:13:06Z","receivedAt":"2015-04-29T17:13:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> ... would behave incorrectly without \"-r\". I would be shocked if that ever\n> happens in real life, but I think it doesn't hurt to be careful.\n\nAhh, OK.  I overlooked the continued-line possibility.\n\n> $$ is always the pid of the main shell process,...\n\nThanks for straightening me out---I was too lazy to run strace ;-)\n\n> ... But I can imagine a shell that is smart\n> enough to realize a fork is not required in this instance.\n\nYup.  I think that is a natural thing to optimize for implementors\nof shells.\n\nThanks.\n"},{"id":"260190","messageId":"5541203A.6040102@kdbg.org","threadId":"39162","inReplyTo":"xmqqioce6gon.fsf@gitster.dls.corp.google.com","subject":"Re: Bug report : bad filter-branch (OSX only)","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2015-04-29T18:17:30Z","receivedAt":"2015-04-29T18:17:30Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 29.04.2015 um 18:30 schrieb Junio C Hamano:\n> As to s/()/{}/, please tell me what I am doing wrong.  I am getting\n> the same process IDs from all of the $$s and the only difference\n> seems to be variable clobbering.\n\nThe clobbered variable should be irrelevant for our use-case because it \noccurs only in the upstream of a pipeline, which is required to run in a \nsub-shell.\n\n-- Hannes\n"}]}