{"thread":{"id":"11022","subject":"Rebase/cherry-picking idea","startedAt":"2007-11-26T09:02:38Z","lastAt":"2007-11-29T10:17:59Z","messageCount":43,"participants":["Wincent Colaiuta","Benoit Sigoure","Johannes Sixt","Johannes Schindelin","Junio C Hamano","Marco Costalba","Shawn O. Pearce","David Kastrup","Nguyen Thai Ngoc Duy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60920","messageId":"109026BC-408F-451A-8F7C-A4012DD8DBDF@wincent.com","threadId":"11022","inReplyTo":null,"subject":"Rebase/cherry-picking idea","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-26T09:02:38Z","receivedAt":"2007-11-26T09:02:38Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"In using \"git-rebase --interactive\" to re-order commits you \noccasionally get conflicts and will see a message like this:\n\n\tWhen commiting, use the option '-c %s' to retain authorship and message\n\nI was thinking that it might be nice to stash away this commit id \nsomewhere in GIT_DIR so that the user didn't have to explicitly \nremember it, and add a new switch to git-commit that could be used to \nautomatically use that stashed commit id, something like:\n\n\tgit commit --retain\n\nAlthough I most often see this kind of message in interactive \nrebasing, the message is generated in builtin-revert.c when cherry- \npicking, so you can also see it in any other situation where you're \ncherry picking and there's a conflict.\n\nWhat do people think? Would this be a nice usability improvement? Or \nis it adding clutter?\n\nCheers,\nWincent\n"},{"id":"60923","messageId":"C3971B37-F75A-40EE-B30A-E88E5DAFAD55@lrde.epita.fr","threadId":"11022","inReplyTo":"109026BC-408F-451A-8F7C-A4012DD8DBDF@wincent.com","subject":"Re: Rebase/cherry-picking idea","fromName":"Benoit Sigoure","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-11-26T09:32:38Z","receivedAt":"2007-11-26T09:32:38Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Nov 26, 2007, at 10:02 AM, Wincent Colaiuta wrote:\n\n> In using \"git-rebase --interactive\" to re-order commits you \n> occasionally get conflicts and will see a message like this:\n>\n> \tWhen commiting, use the option '-c %s' to retain authorship and \n> message\n>\n> I was thinking that it might be nice to stash away this commit id \n> somewhere in GIT_DIR so that the user didn't have to explicitly \n> remember it, and add a new switch to git-commit that could be used \n> to automatically use that stashed commit id, something like:\n>\n> \tgit commit --retain\n>\n> Although I most often see this kind of message in interactive \n> rebasing, the message is generated in builtin-revert.c when cherry- \n> picking, so you can also see it in any other situation where you're \n> cherry picking and there's a conflict.\n>\n> What do people think? Would this be a nice usability improvement? \n> Or is it adding clutter?\n\n\nI'm not sure but I think this message is just some unwanted \n(misleading) noise, since when you rebase, once you solve the \nconflicts, you git-rebase --continue, you don't git-commit.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"60926","messageId":"D21294CA-6FD0-40F5-B0D6-5155865DA69A@wincent.com","threadId":"11022","inReplyTo":"C3971B37-F75A-40EE-B30A-E88E5DAFAD55@lrde.epita.fr","subject":"Re: Rebase/cherry-picking idea","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-26T11:27:13Z","receivedAt":"2007-11-26T11:27:13Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 26/11/2007, a las 10:32, Benoit Sigoure escribió:\n\n> On Nov 26, 2007, at 10:02 AM, Wincent Colaiuta wrote:\n>\n>> In using \"git-rebase --interactive\" to re-order commits you \n>> occasionally get conflicts and will see a message like this:\n>>\n>> \tWhen commiting, use the option '-c %s' to retain authorship and \n>> message\n>>\n>> I was thinking that it might be nice to stash away this commit id \n>> somewhere in GIT_DIR so that the user didn't have to explicitly \n>> remember it, and add a new switch to git-commit that could be used \n>> to automatically use that stashed commit id, something like:\n>>\n>> \tgit commit --retain\n>>\n>> Although I most often see this kind of message in interactive \n>> rebasing, the message is generated in builtin-revert.c when cherry- \n>> picking, so you can also see it in any other situation where you're \n>> cherry picking and there's a conflict.\n>>\n>> What do people think? Would this be a nice usability improvement? \n>> Or is it adding clutter?\n>\n>\n> I'm not sure but I think this message is just some unwanted \n> (misleading) noise, since when you rebase, once you solve the \n> conflicts, you git-rebase --continue, you don't git-commit.\n\nLooks like you're right. I just did a simple test and it turns out \nthat after a conflict, this:\n\n\tgit commit -c ...\n\tgit rebase --continue\n\nProduces exactly the same history as this:\n\n\tgit rebase --continue\n\nSo I think that misleading noise needs to be suppressed or reworded \nwhen rebasing. Will look into it.\n\nCheers,\nWincent\n"},{"id":"60927","messageId":"CDF48716-F198-4B33-A5F5-8A2DE1F177EB@wincent.com","threadId":"11022","inReplyTo":"D21294CA-6FD0-40F5-B0D6-5155865DA69A@wincent.com","subject":"Re: Rebase/cherry-picking idea","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-26T12:34:16Z","receivedAt":"2007-11-26T12:34:16Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 26/11/2007, a las 12:27, Wincent Colaiuta escribió:\n\n> El 26/11/2007, a las 10:32, Benoit Sigoure escribió:\n>\n>> On Nov 26, 2007, at 10:02 AM, Wincent Colaiuta wrote:\n>>\n>>> In using \"git-rebase --interactive\" to re-order commits you \n>>> occasionally get conflicts and will see a message like this:\n>>>\n>>> \tWhen commiting, use the option '-c %s' to retain authorship and \n>>> message\n>>>\n>>> I was thinking that it might be nice to stash away this commit id \n>>> somewhere in GIT_DIR so that the user didn't have to explicitly \n>>> remember it, and add a new switch to git-commit that could be used \n>>> to automatically use that stashed commit id, something like:\n>>>\n>>> \tgit commit --retain\n>>>\n>>> Although I most often see this kind of message in interactive \n>>> rebasing, the message is generated in builtin-revert.c when cherry- \n>>> picking, so you can also see it in any other situation where \n>>> you're cherry picking and there's a conflict.\n>>>\n>>> What do people think? Would this be a nice usability improvement? \n>>> Or is it adding clutter?\n>>\n>>\n>> I'm not sure but I think this message is just some unwanted \n>> (misleading) noise, since when you rebase, once you solve the \n>> conflicts, you git-rebase --continue, you don't git-commit.\n>\n> Looks like you're right. I just did a simple test and it turns out \n> that after a conflict, this:\n>\n> \tgit commit -c ...\n> \tgit rebase --continue\n>\n> Produces exactly the same history as this:\n>\n> \tgit rebase --continue\n>\n> So I think that misleading noise needs to be suppressed or reworded \n> when rebasing. Will look into it.\n\nHow about something like this? It would obviously be nice if we could \navoid adding another option to builtin-revert; perhaps when/if git- \nrebase becomes a builtin we can avoid that. The other alternative, and \nprobably one I like I bit more, would be to auto-detect that a rebase \nis in progress by looking inside the GIT_DIR, although that would also \nalter the behaviour of manual invocations of git-revert and git-cherry- \npick during an interactive rebase (do people actually do that?). What \ndo you think?\n\ndiff --git a/builtin-revert.c b/builtin-revert.c\nindex a0586f9..36e36c3 100644\n--- a/builtin-revert.c\n+++ b/builtin-revert.c\n@@ -30,7 +30,7 @@ static const char * const cherry_pick_usage[] = {\n \tNULL\n };\n\n-static int edit, no_replay, no_commit, mainline;\n+static int edit, no_replay, no_commit, rebasing, mainline;\n static enum { REVERT, CHERRY_PICK } action;\n static struct commit *commit;\n\n@@ -50,6 +50,7 @@ static void parse_args(int argc, const char **argv)\n \t\tOPT_BOOLEAN('e', \"edit\", &edit, \"edit the commit message\"),\n \t\tOPT_BOOLEAN('x', NULL, &no_replay, \"append commit name when cherry- \npicking\"),\n \t\tOPT_BOOLEAN('r', NULL, &noop, \"no-op (backward compatibility)\"),\n+\t\tOPT_BOOLEAN(0, \"rebasing\", &rebasing, \"use rebase mode\"),\n \t\tOPT_INTEGER('m', \"mainline\", &mainline, \"parent number\"),\n \t\tOPT_END(),\n \t};\n@@ -352,11 +353,16 @@ static int revert_or_cherry_pick(int argc, const \nchar **argv)\n \t\t}\n \t\tif (close(msg_fd) || commit_lock_file(&msg_file) < 0)\n \t\t\tdie (\"Error wrapping up %s\", defmsg);\n+\t\tif (rebasing)\n+\t\t\tmessage = \"run 'git rebase --continue' \"\n+\t\t\t \"or 'git rebase --abort'\";\n+\t\telse\n+\t\t\tmessage = \"commit the result\";\n \t\tfprintf(stderr, \"Automatic %s failed. \"\n \t\t\t\"After resolving the conflicts,\\n\"\n \t\t\t\"mark the corrected paths with 'git add ' \"\n-\t\t\t\"and commit the result.\\n\", me);\n-\t\tif (action == CHERRY_PICK) {\n+\t\t\t\"and %s.\\n\", me, message);\n+\t\tif (action == CHERRY_PICK && !rebasing) {\n \t\t\tfprintf(stderr, \"When commiting, use the option \"\n \t\t\t\t\"'-c %s' to retain authorship and message.\\n\",\n \t\t\t\tfind_unique_abbrev(commit->object.sha1,\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex bf44b6a..5afb843 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -117,7 +117,7 @@ pick_one () {\n \t\tsha1=$(git rev-parse --short $sha1)\n \t\toutput warn Fast forward to $sha1\n \telse\n-\t\toutput git cherry-pick \"$@\"\n+\t\toutput git cherry-pick --rebasing \"$@\"\n \tfi\n }\n\n@@ -187,7 +187,7 @@ pick_one_preserving_merges () {\n \t\t\tfi\n \t\t\t;;\n \t\t*)\n-\t\t\toutput git cherry-pick \"$@\" ||\n+\t\t\toutput git cherry-pick --rebasing \"$@\" ||\n \t\t\t\tdie_with_patch $sha1 \"Could not pick $sha1\"\n \t\t\t;;\n \t\tesac\n"},{"id":"60928","messageId":"B14406EA-E1E8-4737-8FCE-853A3BBBE34C@lrde.epita.fr","threadId":"11022","inReplyTo":"CDF48716-F198-4B33-A5F5-8A2DE1F177EB@wincent.com","subject":"Re: Rebase/cherry-picking idea","fromName":"Benoit Sigoure","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-11-26T12:39:42Z","receivedAt":"2007-11-26T12:39:42Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Nov 26, 2007, at 1:34 PM, Wincent Colaiuta wrote:\n\n> How about something like this? It would obviously be nice if we \n> could avoid adding another option to builtin-revert; perhaps when/ \n> if git-rebase becomes a builtin we can avoid that. The other \n> alternative, and probably one I like I bit more, would be to auto- \n> detect that a rebase is in progress by looking inside the GIT_DIR, \n> although that would also alter the behaviour of manual invocations \n> of git-revert and git-cherry-pick during an interactive rebase (do \n> people actually do that?). What do you think?\n\n\nHmm yeah, I agree that it's a little bit of a dirty workaround but, \nas you pointed out, until rebase is builtinified, this looks like the \nbest/easiest alternative.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n"},{"id":"60931","messageId":"474AC136.8060906@viscovery.net","threadId":"11022","inReplyTo":"CDF48716-F198-4B33-A5F5-8A2DE1F177EB@wincent.com","subject":"Re: Rebase/cherry-picking idea","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-26T12:51:02Z","receivedAt":"2007-11-26T12:51:02Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Wincent Colaiuta schrieb:\n> El 26/11/2007, a las 12:27, Wincent Colaiuta escribió:\n>> So I think that misleading noise needs to be suppressed or reworded \n>> when rebasing. Will look into it.\n> \n> How about something like this? It would obviously be nice if we could \n> avoid adding another option to builtin-revert; perhaps when/if \n> git-rebase becomes a builtin we can avoid that. The other alternative, \n> and probably one I like I bit more, would be to auto-detect that a \n> rebase is in progress by looking inside the GIT_DIR, although that would \n> also alter the behaviour of manual invocations of git-revert and \n> git-cherry-pick during an interactive rebase (do people actually do \n> that?). What do you think?\n\nIntroduce an environment variable _GIT_CHERRY_PICK_HELP (note the leading \nunderscore), which git-rebase sets; if it's set, git-cherry-pick uses that \ntext instead of the usual one.\n\n-- Hannes\n"},{"id":"60933","messageId":"451492C9-F3EA-4C37-A1AD-59FC72E0A0A2@wincent.com","threadId":"11022","inReplyTo":"474AC136.8060906@viscovery.net","subject":"Re: Rebase/cherry-picking idea","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-26T13:15:29Z","receivedAt":"2007-11-26T13:15:29Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 26/11/2007, a las 13:51, Johannes Sixt escribió:\n\n> Wincent Colaiuta schrieb:\n>> El 26/11/2007, a las 12:27, Wincent Colaiuta escribió:\n>>> So I think that misleading noise needs to be suppressed or \n>>> reworded when rebasing. Will look into it.\n>> How about something like this? It would obviously be nice if we \n>> could avoid adding another option to builtin-revert; perhaps when/ \n>> if git-rebase becomes a builtin we can avoid that. The other \n>> alternative, and probably one I like I bit more, would be to auto- \n>> detect that a rebase is in progress by looking inside the GIT_DIR, \n>> although that would also alter the behaviour of manual invocations \n>> of git-revert and git-cherry-pick during an interactive rebase (do \n>> people actually do that?). What do you think?\n>\n> Introduce an environment variable _GIT_CHERRY_PICK_HELP (note the \n> leading underscore), which git-rebase sets; if it's set, git-cherry- \n> pick uses that text instead of the usual one.\n\nGood idea, quite a bit less cruddy:\n\ndiff --git a/builtin-revert.c b/builtin-revert.c\nindex a0586f9..5a57574 100644\n--- a/builtin-revert.c\n+++ b/builtin-revert.c\n@@ -229,7 +229,7 @@ static int revert_or_cherry_pick(int argc, const \nchar **argv)\n \tunsigned char head[20];\n \tstruct commit *base, *next, *parent;\n \tint i;\n-\tchar *oneline, *reencoded_message = NULL;\n+\tchar *oneline, *reencoded_message = NULL, *help_message;\n \tconst char *message, *encoding;\n \tconst char *defmsg = xstrdup(git_path(\"MERGE_MSG\"));\n\n@@ -352,11 +352,13 @@ static int revert_or_cherry_pick(int argc, const \nchar **argv)\n \t\t}\n \t\tif (close(msg_fd) || commit_lock_file(&msg_file) < 0)\n \t\t\tdie (\"Error wrapping up %s\", defmsg);\n+\t\thelp_message = getenv(\"_GIT_CHERRY_PICK_HELP\");\n \t\tfprintf(stderr, \"Automatic %s failed. \"\n \t\t\t\"After resolving the conflicts,\\n\"\n \t\t\t\"mark the corrected paths with 'git add ' \"\n-\t\t\t\"and commit the result.\\n\", me);\n-\t\tif (action == CHERRY_PICK) {\n+\t\t\t\"and %s.\\n\", me,\n+\t\t\thelp_message ? help_message : \"commit the result\");\n+\t\tif (action == CHERRY_PICK && !help_message) {\n \t\t\tfprintf(stderr, \"When commiting, use the option \"\n \t\t\t\t\"'-c %s' to retain authorship and message.\\n\",\n \t\t\t\tfind_unique_abbrev(commit->object.sha1,\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex bf44b6a..e5f9810 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -117,6 +117,7 @@ pick_one () {\n \t\tsha1=$(git rev-parse --short $sha1)\n \t\toutput warn Fast forward to $sha1\n \telse\n+\t\texport _GIT_CHERRY_PICK_HELP=\"run 'git rebase --continue'\"\n \t\toutput git cherry-pick \"$@\"\n \tfi\n }\n@@ -187,6 +188,7 @@ pick_one_preserving_merges () {\n \t\t\tfi\n \t\t\t;;\n \t\t*)\n+\t\t\texport _GIT_CHERRY_PICK_HELP=\"run 'git rebase --continue'\"\n \t\t\toutput git cherry-pick \"$@\" ||\n \t\t\t\tdie_with_patch $sha1 \"Could not pick $sha1\"\n \t\t\t;;\n"},{"id":"60934","messageId":"Pine.LNX.4.64.0711261325440.27959@racer.site","threadId":"11022","inReplyTo":"C3971B37-F75A-40EE-B30A-E88E5DAFAD55@lrde.epita.fr","subject":"Re: Rebase/cherry-picking idea","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-26T13:26:43Z","receivedAt":"2007-11-26T13:26:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Nov 2007, Benoit Sigoure wrote:\n\n> On Nov 26, 2007, at 10:02 AM, Wincent Colaiuta wrote:\n> \n> > In using \"git-rebase --interactive\" to re-order commits you occasionally get\n> > conflicts and will see a message like this:\n> > \n> > \tWhen commiting, use the option '-c %s' to retain authorship and\n> > message\n> > \n> > I was thinking that it might be nice to stash away this commit id somewhere\n> > in GIT_DIR so that the user didn't have to explicitly remember it, and add a\n> > new switch to git-commit that could be used to automatically use that\n> > stashed commit id, something like:\n> > \n> > \tgit commit --retain\n> > \n> > Although I most often see this kind of message in interactive rebasing, the\n> > message is generated in builtin-revert.c when cherry-picking, so you can\n> > also see it in any other situation where you're cherry picking and there's a\n> > conflict.\n> > \n> > What do people think? Would this be a nice usability improvement? Or is it\n> > adding clutter?\n> \n> \n> I'm not sure but I think this message is just some unwanted (misleading)\n> noise, since when you rebase, once you solve the conflicts, you git-rebase\n> --continue, you don't git-commit.\n\nYep. It is on my TODO list since a long time, but I am just as glad \nsomebody else is doing it. But I have to agree with Hannes that using an \nenvironment variable is cleaner, more elegant and shorter.\n\nCiao,\nDscho\n"},{"id":"60935","messageId":"Pine.LNX.4.64.0711261340470.27959@racer.site","threadId":"11022","inReplyTo":"451492C9-F3EA-4C37-A1AD-59FC72E0A0A2@wincent.com","subject":"Re: Rebase/cherry-picking idea","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-26T13:41:27Z","receivedAt":"2007-11-26T13:41:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Nov 2007, Wincent Colaiuta wrote:\n\n> +\t\thelp_message = getenv(\"_GIT_CHERRY_PICK_HELP\");\n\nWhy on earth do you have a leading underscore? No existing git \nenvironment variable does it that way.\n\nCiao,\nDscho\n"},{"id":"60936","messageId":"97F6E8DE-4022-4458-B6A9-C644A6EDC1E3@wincent.com","threadId":"11022","inReplyTo":"Pine.LNX.4.64.0711261340470.27959@racer.site","subject":"Re: Rebase/cherry-picking idea","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-26T13:55:56Z","receivedAt":"2007-11-26T13:55:56Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 26/11/2007, a las 14:41, Johannes Schindelin escribió:\n\n> Hi,\n>\n> On Mon, 26 Nov 2007, Wincent Colaiuta wrote:\n>\n>> +\t\thelp_message = getenv(\"_GIT_CHERRY_PICK_HELP\");\n>\n> Why on earth do you have a leading underscore? No existing git\n> environment variable does it that way.\n\nI was following the suggestion of Johannes Sixt:\n\nEl 26/11/2007, a las 13:51, Johannes Sixt escribió:\n\n> Introduce an environment variable _GIT_CHERRY_PICK_HELP (note the \n> leading underscore), which git-rebase sets; if it's set, git-cherry- \n> pick uses that text instead of the usual one.\n\n\nI imagine that he proposed it that way because it's an \"internal use \nonly\" thing.\n\nOnce I get a clear idea of what kind of change is likely to actually \nget accepted I'll submit a proper patch.\n\nCheers,\nWincent\n"},{"id":"60949","messageId":"7vy7ckgbpf.fsf@gitster.siamese.dyndns.org","threadId":"11022","inReplyTo":"474AC136.8060906@viscovery.net","subject":"Re: Rebase/cherry-picking idea","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-26T17:26:20Z","receivedAt":"2007-11-26T17:26:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Introduce an environment variable _GIT_CHERRY_PICK_HELP (note the\n> leading underscore), which git-rebase sets; if it's set,\n> git-cherry-pick uses that text instead of the usual one.\n\nWith precedences like GIT_REFLOG_ACTION and GITHEAD_${objectname}, I\nthink it would be consistent without the leading underscore.\n\nI would not object to renaming all of them to have the leading\nunderscore, though. That would make it clear that they are very\ndifferent from ordinary environment variables for the user to set\n(e.g. GIT_INDEX_FILE, GIT_AUTHOR_NAME). Does any third party tool like\nqgit already use GITHEAD_${objectname} and/or GIT_REFLOG_ACTION?\n"},{"id":"60955","messageId":"e5bfff550711261112s182d9aa8x79e2fc1a0521f2c7@mail.gmail.com","threadId":"11022","inReplyTo":"7vy7ckgbpf.fsf@gitster.siamese.dyndns.org","subject":"Re: Rebase/cherry-picking idea","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-11-26T19:12:20Z","receivedAt":"2007-11-26T19:12:20Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Nov 26, 2007 6:26 PM, Junio C Hamano wrote:\n> (e.g. GIT_INDEX_FILE, GIT_AUTHOR_NAME). Does any third party tool like\n> qgit already use GITHEAD_${objectname} and/or GIT_REFLOG_ACTION?\n>\n\nNo, it doesn't.\n\nThanks for asking ;-)\n\nMarco\n"},{"id":"61012","messageId":"20071127010801.GF14735@spearce.org","threadId":"11022","inReplyTo":"7vy7ckgbpf.fsf@gitster.siamese.dyndns.org","subject":"Re: Rebase/cherry-picking idea","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-27T01:08:01Z","receivedAt":"2007-11-27T01:08:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> I would not object to renaming all of them to have the leading\n> underscore, though. That would make it clear that they are very\n> different from ordinary environment variables for the user to set\n> (e.g. GIT_INDEX_FILE, GIT_AUTHOR_NAME). Does any third party tool like\n> qgit already use GITHEAD_${objectname} and/or GIT_REFLOG_ACTION?\n\ngit-gui apparently doesn't use either name right now. It avoids\nneeding to use GIT_REFLOG_ACTION by invoking only plumbing, except\nin the case of git-merge, where it invokes git-merge and thus avoids\nthe need to set GITHEAD_* to get conflict markers right when the\nrecursive strategy gets used.\n\nI had started to replace git-merge in Tcl and have git-gui directly\ninvoke merge-recursive but I haven't gotten around to really\ndoing that.\n\nSo I guess we could rename those two \"internal\" environment variables\nto use a leading _ to make them different from \"user level\" variables,\nbut why change them now? I really don't see a compelling reason to\nbreak that part of the \"API\" between porcelain/plumbing.\n\n-- \nShawn.\n"},{"id":"61015","messageId":"7vhcj8eay5.fsf@gitster.siamese.dyndns.org","threadId":"11022","inReplyTo":"20071127010801.GF14735@spearce.org","subject":"Re: Rebase/cherry-picking idea","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-27T01:25:38Z","receivedAt":"2007-11-27T01:25:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> So I guess we could rename those two \"internal\" environment variables\n> to use a leading _ to make them different from \"user level\" variables,\n> but why change them now? I really don't see a compelling reason to\n> break that part of the \"API\" between porcelain/plumbing.\n\nI don't either, which means I do not see a compelling reason to have\nunderscore in front of that cherry-pick message environment either.\n\nAbout the patch itself, I think replacing the whole message, not just\n\"and commit the result.\" part, might make more sense.\n\n\thelp_message = getenv(\"_GIT_CHERRY_PICK_HELP\");\n\tfprintf(stderr, \"Automatic %s failed. \"\n\t\t\"After resolving the conflicts,\\n\"\n\t\t\"mark the corrected paths with 'git add ' \"\n\t\t\"and %s.\\n\", me,\n\t\thelp_message ? help_message : \"commit the result\");\n\tif (action == CHERRY_PICK && !help_message) {\n\t\tfprintf(stderr, \"When commiting, use the option \"\n\t\t\t\"'-c %s' to retain authorship and message.\\n\",\n\t\t\tfind_unique_abbrev(commit->object.sha1,\n\t\t\t...\n\nSome other caller can be written to guide the user resolving and do the\n\"git add\" part for the user, and \"mark the corrected paths with 'git add\n'\" may not suit the need for such a caller.\n\nWhich would mean:\n\n\thelp_message = getenv(\"GIT_CHERRY_PICK_HELP\");\n if (!help_message) {\n \tstatic char helpbuf[1024];\n help_message = helpbuf;\n sprintf(help_message,\n \t\" After resolving the conflits,\\n\"\n\t\t\t\"mark the corrected paths with 'git add ' \"\n\t\t\t\"and commit the result.\\n\"\n\t\t\t\"When commiting, use the option \"\n\t\t\t\"'-c %s' to retain authorship and message.\\n\",\n\t\t\tfind_unique_abbrev(commit->object.sha1,\n\t\t\t\t\t\tDEFAULT_ABBREV));\n }\n\tfprintf(stderr, \"Automatic %s failed.%s\", help_message);\n\texit(1);\n\nBut I do not care too deeply either way.\n"},{"id":"61186","messageId":"7vir3m94ku.fsf@gitster.siamese.dyndns.org","threadId":"11022","inReplyTo":"97F6E8DE-4022-4458-B6A9-C644A6EDC1E3@wincent.com","subject":"Re: Rebase/cherry-picking idea","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T08:06:41Z","receivedAt":"2007-11-28T08:06:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"> Once I get a clear idea of what kind of change is likely to actually \n> get accepted I'll submit a proper patch.\n\nToo often, people disappear with a patch that is basically good but has\nroom for improvements this way. I really do not have time nor bandwidth\nto keep bugging them for updates, and often end up cleaning up on my own\ninstead.\n\nThis is such a patch, and without acks or comments, it is also very\nlikely to be lost.\n\n-- >8 --\nrevert/cherry-pick: Allow overriding the help text by the calling Porcelain\n\nA Porcelain command that uses cherry-pick or revert may make a commit\nout of resolved index itself, in which case telling the user to commit\nthe result is not appropriate at all. This allows GIT_CHERRY_PICK_HELP\nenvironment variable to be set by the calling Porcelain in order to\noverride the built-in help text.\n\nSigned-off-by: Junio C Hamano \n---\n\n * I suspect that \"git rebase --continue\" can do \"git add -u\" itself,\n just like recent \"git rebase --skip\" would do \"git reset --hard\".\n\n The overriding help text in this patch can lose its second line that\n tells the user to use \"git add \" if we decide to do so.\n\n builtin-revert.c | 33 +++++++++++++++++++++++----------\n git-rebase--interactive.sh | 5 +++++\n 2 files changed, 28 insertions(+), 10 deletions(-)\n\ndiff --git a/builtin-revert.c b/builtin-revert.c\nindex a0586f9..4f86178 100644\n--- a/builtin-revert.c\n+++ b/builtin-revert.c\n@@ -224,6 +224,27 @@ static int merge_recursive(const char *base_sha1,\n \treturn run_command_v_opt(argv, RUN_COMMAND_NO_STDIN | RUN_GIT_CMD);\n }\n \n+static char *help_msg(const unsigned char *sha1)\n+{\n+\tstatic char helpbuf[1024];\n+\tchar *msg = getenv(\"GIT_CHERRY_PICK_HELP\");\n+\n+\tif (msg)\n+\t\treturn msg;\n+\n+\tstrcpy(helpbuf, \" After resolving the conflicts,\\n\"\n+\t \"mark the corrected paths with 'git add ' \"\n+\t \"and commit the result.\");\n+\n+\tif (action == CHERRY_PICK) {\n+\t\tsprintf(helpbuf + strlen(helpbuf),\n+\t\t\t\"\\nWhen commiting, use the option \"\n+\t\t\t\"'-c %s' to retain authorship and message.\",\n+\t\t\tfind_unique_abbrev(sha1, DEFAULT_ABBREV));\n+\t}\n+\treturn helpbuf;\n+}\n+\n static int revert_or_cherry_pick(int argc, const char **argv)\n {\n \tunsigned char head[20];\n@@ -352,16 +373,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)\n \t\t}\n \t\tif (close(msg_fd) || commit_lock_file(&msg_file) < 0)\n \t\t\tdie (\"Error wrapping up %s\", defmsg);\n-\t\tfprintf(stderr, \"Automatic %s failed. \"\n-\t\t\t\"After resolving the conflicts,\\n\"\n-\t\t\t\"mark the corrected paths with 'git add ' \"\n-\t\t\t\"and commit the result.\\n\", me);\n-\t\tif (action == CHERRY_PICK) {\n-\t\t\tfprintf(stderr, \"When commiting, use the option \"\n-\t\t\t\t\"'-c %s' to retain authorship and message.\\n\",\n-\t\t\t\tfind_unique_abbrev(commit->object.sha1,\n-\t\t\t\t\tDEFAULT_ABBREV));\n-\t\t}\n+\t\tfprintf(stderr, \"Automatic %s failed.%s\\n\",\n+\t\t\tme, help_msg(commit->object.sha1));\n \t\texit(1);\n \t}\n \tif (close(msg_fd) || commit_lock_file(&msg_file) < 0)\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex bf44b6a..33a5d4b 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -30,6 +30,11 @@ test -d \"$REWRITTEN\" && PRESERVE_MERGES=t\n test -f \"$DOTEST\"/strategy && STRATEGY=\"$(cat \"$DOTEST\"/strategy)\"\n test -f \"$DOTEST\"/verbose && VERBOSE=t\n \n+GIT_CHERRY_PICK_HELP=\" After resolving the conflicts,\n+mark the corrected paths with 'git add ', and\n+run 'git rebase --continue'\"\n+export GIT_CHERRY_PICK_HELP\n+\n warn () {\n \techo \"$*\" >&2\n }\n"},{"id":"61195","messageId":"50645A3B-C5F0-4A99-A2B8-AD9251024244@wincent.com","threadId":"11022","inReplyTo":"7vir3m94ku.fsf@gitster.siamese.dyndns.org","subject":"Re: Rebase/cherry-picking idea","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-28T08:52:08Z","receivedAt":"2007-11-28T08:52:08Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 28/11/2007, a las 9:06, Junio C Hamano escribió:\n\n>> Once I get a clear idea of what kind of change is likely to actually\n>> get accepted I'll submit a proper patch.\n>\n> Too often, people disappear with a patch that is basically good but \n> has\n> room for improvements this way. I really do not have time nor \n> bandwidth\n> to keep bugging them for updates, and often end up cleaning up on my \n> own\n> instead.\n\nThe problem in this case was that my patch didn't receive any \nmeaningful feedback (ie. suggestions for improvement), only a lot of \nbikeshed stuff about whether the environment variable should have an \nunderscore prefix or not, whether or not I should use \"export FOO=...\" \nor not etc. So I didn't know what was necessary in order to get it \naccepted.\n\n> This is such a patch, and without acks or comments, it is also very\n> likely to be lost.\n\nOk, please disregard the resend that I just posted a few minutes ago \n(hadn't seen your new patch yet).\n\nCheers,\nWincent\n"},{"id":"61149","messageId":"7v1waa7lcv.fsf@gitster.siamese.dyndns.org","threadId":"11022","inReplyTo":"50645A3B-C5F0-4A99-A2B8-AD9251024244@wincent.com","subject":"Re: Rebase/cherry-picking idea","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T09:47:12Z","receivedAt":"2007-11-28T09:47:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wincent Colaiuta writes:\n\n> The problem in this case was that my patch didn't receive any\n> meaningful feedback (ie. suggestions for improvement), only a lot of\n> bikeshed stuff about whether the environment variable should have an\n> underscore prefix or not, whether or not I should use \"export FOO=...\"\n> or not etc. So I didn't know what was necessary in order to get it\n> accepted.\n\nI do not think that is the case.\n\nI think _GIT_FOO vs GIT_FOO is an important detail, not at all a\nbikeshed color, to make things consistent. \"export VAR=VAL\" also is a\nvalid concern (you said in a separate message you only know about bash,\nand I later asked people if they use shells that get affected with it\nbut we happily run otherwise. I personally do not think the latter is a\nproblem, but since somebody already raised it as a potential issue, it\ngave us a good chance to hear from people on minority platforms, if only\nto build confidence in us to use that POSIX form.\n\nMaybe it is just me, but I think my suggestion to replace not just \"git\ncommit\" part but also \"git add\" part is also an important design issue.\n\nIn any case, after a discussion, sending out a readily applyable patch\nwould help to make sure we reached a reasonable consensus; it makes it\neasier for other people to try out your proposed draft of the consensus\nwithout waiting for me or anybody else and give positive feedback.\n\nThe difference between the variant I posted and your revised one I see\nare:\n\n * As discussed, we have precedence like GITHEAD_* and GIT_REFLOG_ACTION\n that are used purely for inter-tool communication without the leading\n underscore, so I followed them for consistency.\n\n * The part of the message that is overridable is made wider; that way,\n we can later choose to have \"git rebase --continue\" do the final \"git\n add -u\" step, just like we made \"git rebase --skip\" to run \"git reset\n --hard\", without changing revert/cherry-pick,as I explained in the\n comment to my patch.\n\n * I made the help-message creation into a separate function. This is\n just a minor detail, but I think it is good for readability.\n\n * I am setting and exporting the help environment near the beginning of\n rebase--interactive just once; again I think this is more readable.\n\nBut other than that, the basic idea is the same and is all yours.\n\nIf these details (I do not think the overridability is a minor detail,\nthough) look like bikeshedding to you, that is somewhat sad. You seem\nto be very capable of producing usable code, but these details\n(consistency and flexibility) matter for longer term stability, and I\nwould really want to see capable people pay attention to such details,\nespecially I sometimes fail to do so myself.\n"},{"id":"61150","messageId":"1570EAD5-9F47-4105-B3DA-49CA6FA57369@wincent.com","threadId":"11022","inReplyTo":"7v1waa7lcv.fsf@gitster.siamese.dyndns.org","subject":"Re: Rebase/cherry-picking idea","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-28T10:04:58Z","receivedAt":"2007-11-28T10:04:58Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 28/11/2007, a las 10:47, Junio C Hamano escribió:\n\n> I think _GIT_FOO vs GIT_FOO is an important detail, not at all a\n> bikeshed color, to make things consistent. \"export VAR=VAL\" also is a\n> valid concern (you said in a separate message you only know about \n> bash,\n> and I later asked people if they use shells that get affected with it\n> but we happily run otherwise. I personally do not think the latter \n> is a\n> problem, but since somebody already raised it as a potential issue, it\n> gave us a good chance to hear from people on minority platforms, if \n> only\n> to build confidence in us to use that POSIX form.\n\nI'm still a little concerned that nobody commented when I pointed out \nthat export VAR=VAL is used elsewhere in Git, especially in git- \nclone.sh, which is very commonly-used porcelain. Is it a problem?\n\n> If these details (I do not think the overridability is a minor detail,\n> though) look like bikeshedding to you, that is somewhat sad. You seem\n> to be very capable of producing usable code, but these details\n> (consistency and flexibility) matter for longer term stability, and I\n> would really want to see capable people pay attention to such details,\n> especially I sometimes fail to do so myself.\n\n\nI think the *key* difference between our patches was the refactoring \nthat you did (extracting into a separate function and at the same time \nmaking the entire message customizable rather than just the end). I \nthink that's easily explained by the fact that as a new contributor I \nam pretty much always going to err on the side of the most minimal \nchange possible (minimum number of lines, and changes kept as local as \npossible), even if it isn't the best or most well-engineered one. Your \npatch is more invasive, but it's better too, and I think it's more \ninvasive precisely because your knowledge of the codebase and your \ntrack record gives you the confidence to make non-minimal changes when \nyou think they're better. With time I imagine I'll evolve away from \nsuch defensive, minimal patches as the one I sent.\n\nCheers,\nWincent\n"},{"id":"61198","messageId":"Pine.LNX.4.64.0711281355460.27959@racer.site","threadId":"11022","inReplyTo":"1570EAD5-9F47-4105-B3DA-49CA6FA57369@wincent.com","subject":"[PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T13:57:03Z","receivedAt":"2007-11-28T13:57:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nIt might be POSIX, but there are shells that do not like the\nexpression 'export VAR=VAL'. To be on the safe side, rewrite them\ninto 'VAR=VAL' and 'export VAR'.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Wed, 28 Nov 2007, Wincent Colaiuta wrote:\n\n\t> I'm still a little concerned that nobody commented when I \n\t> pointed out that export VAR=VAL is used elsewhere in Git, \n\t> especially in git-clone.sh, which is very commonly-used \n\t> porcelain. Is it a problem?\n\n\tHow's that for a comment?\n\n git-clone.sh | 2 +-\n git-filter-branch.sh | 20 ++++++++++++--------\n git-quiltimport.sh | 10 ++++++----\n 3 files changed, 19 insertions(+), 13 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 24ad179..ecf9d89 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -229,7 +229,7 @@ cleanup() {\n trap cleanup 0\n mkdir -p \"$dir\" && D=$(cd \"$dir\" && pwd) || usage\n test -n \"$GIT_WORK_TREE\" && mkdir -p \"$GIT_WORK_TREE\" &&\n-W=$(cd \"$GIT_WORK_TREE\" && pwd) && export GIT_WORK_TREE=\"$W\"\n+W=$(cd \"$GIT_WORK_TREE\" && pwd) && GIT_WORK_TREE=\"$W\" && export GIT_WORK_TREE\n if test yes = \"$bare\" || test -n \"$GIT_WORK_TREE\"; then\n \tGIT_DIR=\"$D\"\n else\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex 19cab5a..3afc945 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -66,17 +66,17 @@ set_ident () {\n \t\t\th\n \t\t\ts/^'$lid' \\([^<]*\\) <[^>]*> .*$/\\1/\n \t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/export GIT_'$uid'_NAME='\\''&'\\''/p\n+\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\nexport GIT_'$uid'_NAME/p\n \n \t\t\tg\n \t\t\ts/^'$lid' [^<]* <\\([^>]*\\)> .*$/\\1/\n \t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/export GIT_'$uid'_EMAIL='\\''&'\\''/p\n+\t\t\ts/.*/GIT_'$uid'_EMAIL='\\''&'\\''\\nexport GIT_'$uid'_EMAIL/p\n \n \t\t\tg\n \t\t\ts/^'$lid' [^<]* <[^>]*> \\(.*\\)$/\\1/\n \t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/export GIT_'$uid'_DATE='\\''&'\\''/p\n+\t\t\ts/.*/GIT_'$uid'_DATE='\\''&'\\''\\nexport GIT_'$uid'_DATE/p\n \n \t\t\tq\n \t\t}\n@@ -84,7 +84,7 @@ set_ident () {\n \n \tLANG=C LC_ALL=C sed -ne \"$pick_id_script\"\n \t# Ensure non-empty id name.\n-\techo \"[ -n \\\"\\$GIT_${uid}_NAME\\\" ] || export GIT_${uid}_NAME=\\\"\\${GIT_${uid}_EMAIL%%@*}\\\"\"\n+\techo \"case \\\"\\$GIT_${uid}_NAME\\\" in \\\"\\\") GIT_${uid}_NAME=\\\"\\${GIT_${uid}_EMAIL%%@*}\\\" && export GIT_${uid}_NAME;; esac\"\n }\n \n USAGE=\"[--env-filter ] [--tree-filter ] \\\n@@ -206,7 +206,8 @@ done < \"$tempdir\"/backup-refs\n ORIG_GIT_DIR=\"$GIT_DIR\"\n ORIG_GIT_WORK_TREE=\"$GIT_WORK_TREE\"\n ORIG_GIT_INDEX_FILE=\"$GIT_INDEX_FILE\"\n-export GIT_DIR GIT_WORK_TREE=.\n+GIT_WORK_TREE=.\n+export GIT_DIR GIT_WORK_TREE\n \n # These refs should be updated if their heads were rewritten\n \n@@ -231,7 +232,8 @@ done > \"$tempdir\"/heads\n test -s \"$tempdir\"/heads ||\n \tdie \"Which ref do you want to rewrite?\"\n \n-export GIT_INDEX_FILE=\"$(pwd)/../index\"\n+GIT_INDEX_FILE=\"$(pwd)/../index\"\n+export GIT_INDEX_FILE\n git read-tree || die \"Could not seed the index\"\n \n ret=0\n@@ -267,7 +269,8 @@ while read commit parents; do\n \t\tgit read-tree -i -m $commit:\"$filter_subdir\"\n \tesac || die \"Could not initialize the index\"\n \n-\texport GIT_COMMIT=$commit\n+\tGIT_COMMIT=$commit\n+\texport GIT_COMMIT\n \tgit cat-file commit \"$commit\" >../commit ||\n \t\tdie \"Cannot read commit $commit\"\n \n@@ -401,7 +404,8 @@ if [ \"$filter_tag_name\" ]; then\n \n \t\t[ -f \"../map/$sha1\" ] || continue\n \t\tnew_sha1=\"$(cat \"../map/$sha1\")\"\n-\t\texport GIT_COMMIT=\"$sha1\"\n+\t\tGIT_COMMIT=\"$sha1\"\n+\t\texport GIT_COMMIT\n \t\tnew_ref=\"$(echo \"$ref\" | eval \"$filter_tag_name\")\" ||\n \t\t\tdie \"tag name filter failed: $filter_tag_name\"\n \ndiff --git a/git-quiltimport.sh b/git-quiltimport.sh\nindex 6b0c4d2..233e5ea 100755\n--- a/git-quiltimport.sh\n+++ b/git-quiltimport.sh\n@@ -77,8 +77,9 @@ for patch_name in $(grep -v '^#' < \"$QUILT_PATCHES/series\" ); do\n \t}\n \n \t# Parse the author information\n-\texport GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' \"$tmp_info\")\n-\texport GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' \"$tmp_info\")\n+\tGIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' \"$tmp_info\")\n+\tGIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' \"$tmp_info\")\n+\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL\n \twhile test -z \"$GIT_AUTHOR_EMAIL\" && test -z \"$GIT_AUTHOR_NAME\" ; do\n \t\tif [ -n \"$quilt_author\" ] ; then\n \t\t\tGIT_AUTHOR_NAME=\"$quilt_author_name\";\n@@ -104,8 +105,9 @@ for patch_name in $(grep -v '^#' < \"$QUILT_PATCHES/series\" ); do\n \t\t\tGIT_AUTHOR_EMAIL=\"$patch_author_email\"\n \t\tfi\n \tdone\n-\texport GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' \"$tmp_info\")\n-\texport SUBJECT=$(sed -ne 's/Subject: //p' \"$tmp_info\")\n+\tGIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' \"$tmp_info\")\n+\tSUBJECT=$(sed -ne 's/Subject: //p' \"$tmp_info\")\n+\texport GIT_AUTHOR_DATE SUBJECT\n \tif [ -z \"$SUBJECT\" ] ; then\n \t\tSUBJECT=$(echo $patch_name | sed -e 's/.patch$//')\n \tfi\n-- \n1.5.3.6.2064.g4e322\n"},{"id":"61200","messageId":"85prxua2bu.fsf@lola.goethe.zz","threadId":"11022","inReplyTo":"Pine.LNX.4.64.0711281355460.27959@racer.site","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-28T14:09:57Z","receivedAt":"2007-11-28T14:09:57Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> It might be POSIX, but there are shells that do not like the\n> expression 'export VAR=VAL'. To be on the safe side, rewrite them\n> into 'VAR=VAL' and 'export VAR'.\n\nThis seems like activism to me: if no supported shell has a problem with\nthat construct, why bother?\n\nThere probably should be a list of shells we try supporting, and in\nparticular a list of those where we don't bother.\n\nAnd if a POSIX construct is supported by all shells we try supporting, I\ndon't see a point in patching it away.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"61202","messageId":"fcaeb9bf0711280619j3479ea6csa74f4b0d907f2a65@mail.gmail.com","threadId":"11022","inReplyTo":"Pine.LNX.4.64.0711281355460.27959@racer.site","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-28T14:19:05Z","receivedAt":"2007-11-28T14:19:05Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 28, 2007 8:57 PM, Johannes Schindelin wrote:\n>\n> It might be POSIX, but there are shells that do not like the\n> expression 'export VAR=VAL'. To be on the safe side, rewrite them\n> into 'VAR=VAL' and 'export VAR'.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n>\n> On Wed, 28 Nov 2007, Wincent Colaiuta wrote:\n>\n> > I'm still a little concerned that nobody commented when I\n> > pointed out that export VAR=VAL is used elsewhere in Git,\n> > especially in git-clone.sh, which is very commonly-used\n> > porcelain. Is it a problem?\n>\n> How's that for a comment?\n>\n> git-clone.sh | 2 +-\n> git-filter-branch.sh | 20 ++++++++++++--------\n> git-quiltimport.sh | 10 ++++++----\n> 3 files changed, 19 insertions(+), 13 deletions(-)\n\nWhy leave test scripts behind?\n\n-- \nDuy\n"},{"id":"61203","messageId":"474D7956.8050401@viscovery.net","threadId":"11022","inReplyTo":"Pine.LNX.4.64.0711281355460.27959@racer.site","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-28T14:21:10Z","receivedAt":"2007-11-28T14:21:10Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> -\t\t\ts/.*/export GIT_'$uid'_NAME='\\''&'\\''/p\n> +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\nexport GIT_'$uid'_NAME/p\n\nRecently there was a report that \\n in the substitution side of s/// is not \nsupported by all seds :-(\n\n> -\texport GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' \"$tmp_info\")\n> -\texport GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' \"$tmp_info\")\n> +\tGIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' \"$tmp_info\")\n> +\tGIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' \"$tmp_info\")\n> +\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL\n\nThis even fixes a bug: ash supports export VAR=VAL, but *does* word-split \nVAL if it is not quoted.\n\n-- Hannes\n"},{"id":"61204","messageId":"85lk8ia1nw.fsf@lola.goethe.zz","threadId":"11022","inReplyTo":"fcaeb9bf0711280619j3479ea6csa74f4b0d907f2a65@mail.gmail.com","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-28T14:24:19Z","receivedAt":"2007-11-28T14:24:19Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Nguyen Thai Ngoc Duy\" writes:\n\n> On Nov 28, 2007 8:57 PM, Johannes Schindelin wrote:\n>>\n>> It might be POSIX, but there are shells that do not like the\n>> expression 'export VAR=VAL'. To be on the safe side, rewrite them\n>> into 'VAR=VAL' and 'export VAR'.\n>\n> Why leave test scripts behind?\n\nGood keyword: how about starting the basic tests by testing for shell\nfeatures that are known and accepted to be used in git?\n\nThat way, we get direct feedback when feature assumptions are\nproblematic with some shells.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"61205","messageId":"fcaeb9bf0711280627h1ac216bbr98dc986b82a54423@mail.gmail.com","threadId":"11022","inReplyTo":"85lk8ia1nw.fsf@lola.goethe.zz","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-28T14:27:21Z","receivedAt":"2007-11-28T14:27:21Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 28, 2007 9:24 PM, David Kastrup wrote:\n> \"Nguyen Thai Ngoc Duy\" writes:\n>\n> > On Nov 28, 2007 8:57 PM, Johannes Schindelin wrote:\n> >>\n> >> It might be POSIX, but there are shells that do not like the\n> >> expression 'export VAR=VAL'. To be on the safe side, rewrite them\n> >> into 'VAR=VAL' and 'export VAR'.\n> >\n> > Why leave test scripts behind?\n>\n> Good keyword: how about starting the basic tests by testing for shell\n> features that are known and accepted to be used in git?\n>\n> That way, we get direct feedback when feature assumptions are\n> problematic with some shells.\n\nUh.. I meant there are \"export VAL=VAL\" usage in test scripts and they\nshould be fixed as well. Anyway your idea is nice.\n-- \nDuy\n"},{"id":"61206","messageId":"Pine.LNX.4.64.0711281426370.27959@racer.site","threadId":"11022","inReplyTo":"fcaeb9bf0711280619j3479ea6csa74f4b0d907f2a65@mail.gmail.com","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T14:27:53Z","receivedAt":"2007-11-28T14:27:53Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On Nov 28, 2007 8:57 PM, Johannes Schindelin wrote:\n> >\n> > It might be POSIX, but there are shells that do not like the\n> > expression 'export VAR=VAL'. To be on the safe side, rewrite them\n> > into 'VAR=VAL' and 'export VAR'.\n> >\n> > Signed-off-by: Johannes Schindelin \n> > ---\n> >\n> > On Wed, 28 Nov 2007, Wincent Colaiuta wrote:\n> >\n> > > I'm still a little concerned that nobody commented when I\n> > > pointed out that export VAR=VAL is used elsewhere in Git,\n> > > especially in git-clone.sh, which is very commonly-used\n> > > porcelain. Is it a problem?\n> >\n> > How's that for a comment?\n> >\n> > git-clone.sh | 2 +-\n> > git-filter-branch.sh | 20 ++++++++++++--------\n> > git-quiltimport.sh | 10 ++++++----\n> > 3 files changed, 19 insertions(+), 13 deletions(-)\n> \n> Why leave test scripts behind?\n\nBecause I did a\n\n\tgit grep 'export.*=' *.sh\n\ninstead of a\n\n\tgit grep 'export.*=' -- \\*.sh\n\nBut this patch is\n\n- good of its own, and\n\n- a comment ;-)\n\nCiao,\nDscho\n"},{"id":"61207","messageId":"Pine.LNX.4.64.0711281428180.27959@racer.site","threadId":"11022","inReplyTo":"474D7956.8050401@viscovery.net","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T14:29:11Z","receivedAt":"2007-11-28T14:29:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Johannes Sixt wrote:\n\n> Johannes Schindelin schrieb:\n> > -\t\t\ts/.*/export GIT_'$uid'_NAME='\\''&'\\''/p\n> > +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\nexport\n> > GIT_'$uid'_NAME/p\n> \n> Recently there was a report that \\n in the substitution side of s/// is not\n> supported by all seds :-(\n\nOkay, how about replacing the line with\n\n+\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\\n+export GIT_'$uid'_NAME/p\n\nHmm? (It works here.)\n\nCiao,\nDscho\n"},{"id":"61208","messageId":"Pine.LNX.4.64.0711281435470.27959@racer.site","threadId":"11022","inReplyTo":"fcaeb9bf0711280627h1ac216bbr98dc986b82a54423@mail.gmail.com","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T14:36:32Z","receivedAt":"2007-11-28T14:36:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\n\nOn Wed, 28 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n\n> > how about starting the basic tests by testing for shell features that \n> > are known and accepted to be used in git?\n> >\n> > That way, we get direct feedback when feature assumptions are \n> > problematic with some shells.\n> \n> Uh.. I meant there are \"export VAL=VAL\" usage in test scripts and they \n> should be fixed as well. Anyway your idea is nice.\n\nI have an even better idea: how about getting rid of all shell scripts, \nmaking them builtins? ;-)\n\nCiao,\nDscho\n"},{"id":"61209","messageId":"474D7D92.2000106@viscovery.net","threadId":"11022","inReplyTo":"Pine.LNX.4.64.0711281428180.27959@racer.site","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-28T14:39:14Z","receivedAt":"2007-11-28T14:39:14Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> Hi,\n> \n> On Wed, 28 Nov 2007, Johannes Sixt wrote:\n> \n>> Johannes Schindelin schrieb:\n>>> -\t\t\ts/.*/export GIT_'$uid'_NAME='\\''&'\\''/p\n>>> +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\nexport\n>>> GIT_'$uid'_NAME/p\n>> Recently there was a report that \\n in the substitution side of s/// is not\n>> supported by all seds :-(\n> \n> Okay, how about replacing the line with\n> \n> +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\\n> +export GIT_'$uid'_NAME/p\n> \n> Hmm? (It works here.)\n\nThis looks good. The other case I'm refering to was also solved in this way.\n\n-- Hannes\n"},{"id":"61210","messageId":"85aboya0vw.fsf@lola.goethe.zz","threadId":"11022","inReplyTo":"Pine.LNX.4.64.0711281428180.27959@racer.site","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-28T14:41:07Z","receivedAt":"2007-11-28T14:41:07Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 28 Nov 2007, Johannes Sixt wrote:\n>\n>> Johannes Schindelin schrieb:\n>> > -\t\t\ts/.*/export GIT_'$uid'_NAME='\\''&'\\''/p\n>> > +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\nexport\n>> > GIT_'$uid'_NAME/p\n>> \n>> Recently there was a report that \\n in the substitution side of s/// is not\n>> supported by all seds :-(\n>\n> Okay, how about replacing the line with\n>\n> +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\\n> +export GIT_'$uid'_NAME/p\n>\n> Hmm? (It works here.)\n\nDo we really want to replace code which is not as far as I know known to\nfail under any of the supported shells with something which quite\npossibly relies on particular sed implementations (and we have fewer\nportability guarantees or even experience about sed than about the\nshell, right?)?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"61224","messageId":"Pine.LNX.4.64.0711281552440.27959@racer.site","threadId":"11022","inReplyTo":"474D7D92.2000106@viscovery.net","subject":"[PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T15:56:11Z","receivedAt":"2007-11-28T15:56:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nIt might be POSIX, but there are shells that do not like the\nexpression 'export VAR=VAL'. To be on the safe side, rewrite them\ninto 'VAR=VAL' and 'export VAR'.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Wed, 28 Nov 2007, Johannes Sixt wrote:\n\n\t> Johannes Schindelin schrieb:\n\t> > \n\t> > On Wed, 28 Nov 2007, Johannes Sixt wrote:\n\t> > \n\t> > > Johannes Schindelin schrieb:\n\t> > > > -\t\t\ts/.*/export GIT_'$uid'_NAME='\\''&'\\''/p\n\t> > > > +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\nexport\n\t> > > > GIT_'$uid'_NAME/p\n\t> > >\n\t> > > Recently there was a report that \\n in the substitution side \n\t> > > of s/// is not supported by all seds :-(\n\t> > \n\t> > Okay, how about replacing the line with\n\t> > \n\t> > +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\\n\t> > +export GIT_'$uid'_NAME/p\n\t> > \n\t> > Hmm? (It works here.)\n\t> \n\t> This looks good. The other case I'm refering to was also solved \n\t> in this way.\n\n\tDone.\n\n git-clone.sh | 2 +-\n git-filter-branch.sh | 23 +++++++++++++++--------\n git-quiltimport.sh | 10 ++++++----\n 3 files changed, 22 insertions(+), 13 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 24ad179..ecf9d89 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -229,7 +229,7 @@ cleanup() {\n trap cleanup 0\n mkdir -p \"$dir\" && D=$(cd \"$dir\" && pwd) || usage\n test -n \"$GIT_WORK_TREE\" && mkdir -p \"$GIT_WORK_TREE\" &&\n-W=$(cd \"$GIT_WORK_TREE\" && pwd) && export GIT_WORK_TREE=\"$W\"\n+W=$(cd \"$GIT_WORK_TREE\" && pwd) && GIT_WORK_TREE=\"$W\" && export GIT_WORK_TREE\n if test yes = \"$bare\" || test -n \"$GIT_WORK_TREE\"; then\n \tGIT_DIR=\"$D\"\n else\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex 19cab5a..074b2c0 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -66,17 +66,20 @@ set_ident () {\n \t\t\th\n \t\t\ts/^'$lid' \\([^<]*\\) <[^>]*> .*$/\\1/\n \t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/export GIT_'$uid'_NAME='\\''&'\\''/p\n+\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\\n+export GIT_'$uid'_NAME/p\n \n \t\t\tg\n \t\t\ts/^'$lid' [^<]* <\\([^>]*\\)> .*$/\\1/\n \t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/export GIT_'$uid'_EMAIL='\\''&'\\''/p\n+\t\t\ts/.*/GIT_'$uid'_EMAIL='\\''&'\\''\\\n+export GIT_'$uid'_EMAIL/p\n \n \t\t\tg\n \t\t\ts/^'$lid' [^<]* <[^>]*> \\(.*\\)$/\\1/\n \t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/export GIT_'$uid'_DATE='\\''&'\\''/p\n+\t\t\ts/.*/GIT_'$uid'_DATE='\\''&'\\''\\\n+export GIT_'$uid'_DATE/p\n \n \t\t\tq\n \t\t}\n@@ -84,7 +87,7 @@ set_ident () {\n \n \tLANG=C LC_ALL=C sed -ne \"$pick_id_script\"\n \t# Ensure non-empty id name.\n-\techo \"[ -n \\\"\\$GIT_${uid}_NAME\\\" ] || export GIT_${uid}_NAME=\\\"\\${GIT_${uid}_EMAIL%%@*}\\\"\"\n+\techo \"case \\\"\\$GIT_${uid}_NAME\\\" in \\\"\\\") GIT_${uid}_NAME=\\\"\\${GIT_${uid}_EMAIL%%@*}\\\" && export GIT_${uid}_NAME;; esac\"\n }\n \n USAGE=\"[--env-filter ] [--tree-filter ] \\\n@@ -206,7 +209,8 @@ done < \"$tempdir\"/backup-refs\n ORIG_GIT_DIR=\"$GIT_DIR\"\n ORIG_GIT_WORK_TREE=\"$GIT_WORK_TREE\"\n ORIG_GIT_INDEX_FILE=\"$GIT_INDEX_FILE\"\n-export GIT_DIR GIT_WORK_TREE=.\n+GIT_WORK_TREE=.\n+export GIT_DIR GIT_WORK_TREE\n \n # These refs should be updated if their heads were rewritten\n \n@@ -231,7 +235,8 @@ done > \"$tempdir\"/heads\n test -s \"$tempdir\"/heads ||\n \tdie \"Which ref do you want to rewrite?\"\n \n-export GIT_INDEX_FILE=\"$(pwd)/../index\"\n+GIT_INDEX_FILE=\"$(pwd)/../index\"\n+export GIT_INDEX_FILE\n git read-tree || die \"Could not seed the index\"\n \n ret=0\n@@ -267,7 +272,8 @@ while read commit parents; do\n \t\tgit read-tree -i -m $commit:\"$filter_subdir\"\n \tesac || die \"Could not initialize the index\"\n \n-\texport GIT_COMMIT=$commit\n+\tGIT_COMMIT=$commit\n+\texport GIT_COMMIT\n \tgit cat-file commit \"$commit\" >../commit ||\n \t\tdie \"Cannot read commit $commit\"\n \n@@ -401,7 +407,8 @@ if [ \"$filter_tag_name\" ]; then\n \n \t\t[ -f \"../map/$sha1\" ] || continue\n \t\tnew_sha1=\"$(cat \"../map/$sha1\")\"\n-\t\texport GIT_COMMIT=\"$sha1\"\n+\t\tGIT_COMMIT=\"$sha1\"\n+\t\texport GIT_COMMIT\n \t\tnew_ref=\"$(echo \"$ref\" | eval \"$filter_tag_name\")\" ||\n \t\t\tdie \"tag name filter failed: $filter_tag_name\"\n \ndiff --git a/git-quiltimport.sh b/git-quiltimport.sh\nindex 6b0c4d2..233e5ea 100755\n--- a/git-quiltimport.sh\n+++ b/git-quiltimport.sh\n@@ -77,8 +77,9 @@ for patch_name in $(grep -v '^#' < \"$QUILT_PATCHES/series\" ); do\n \t}\n \n \t# Parse the author information\n-\texport GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' \"$tmp_info\")\n-\texport GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' \"$tmp_info\")\n+\tGIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' \"$tmp_info\")\n+\tGIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' \"$tmp_info\")\n+\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL\n \twhile test -z \"$GIT_AUTHOR_EMAIL\" && test -z \"$GIT_AUTHOR_NAME\" ; do\n \t\tif [ -n \"$quilt_author\" ] ; then\n \t\t\tGIT_AUTHOR_NAME=\"$quilt_author_name\";\n@@ -104,8 +105,9 @@ for patch_name in $(grep -v '^#' < \"$QUILT_PATCHES/series\" ); do\n \t\t\tGIT_AUTHOR_EMAIL=\"$patch_author_email\"\n \t\tfi\n \tdone\n-\texport GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' \"$tmp_info\")\n-\texport SUBJECT=$(sed -ne 's/Subject: //p' \"$tmp_info\")\n+\tGIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' \"$tmp_info\")\n+\tSUBJECT=$(sed -ne 's/Subject: //p' \"$tmp_info\")\n+\texport GIT_AUTHOR_DATE SUBJECT\n \tif [ -z \"$SUBJECT\" ] ; then\n \t\tSUBJECT=$(echo $patch_name | sed -e 's/.patch$//')\n \tfi\n-- \n1.5.3.6.2065.gd47ac\n"},{"id":"61229","messageId":"85ve7m8iix.fsf@lola.goethe.zz","threadId":"11022","inReplyTo":"Pine.LNX.4.64.0711281552440.27959@racer.site","subject":"Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-28T16:03:02Z","receivedAt":"2007-11-28T16:03:02Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> It might be POSIX, but there are shells that do not like the\n> expression 'export VAR=VAL'.\n\nAs long as we have no positive report about any such shell that\n_otherwise_ would be usable for git, why bother?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"61265","messageId":"7vve7m5hwo.fsf@gitster.siamese.dyndns.org","threadId":"11022","inReplyTo":"1570EAD5-9F47-4105-B3DA-49CA6FA57369@wincent.com","subject":"Re: Rebase/cherry-picking idea","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T18:44:39Z","receivedAt":"2007-11-28T18:44:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wincent Colaiuta writes:\n\n> I'm still a little concerned that nobody commented when I pointed out\n> that export VAR=VAL is used elsewhere in Git, especially in git-\n> clone.sh, which is very commonly-used porcelain. Is it a problem?\n\nWe are waiting to find out, aren't we, after having the discussion.\n"},{"id":"61266","messageId":"7vr6ia5hoi.fsf@gitster.siamese.dyndns.org","threadId":"11022","inReplyTo":"474D7D92.2000106@viscovery.net","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T18:49:33Z","receivedAt":"2007-11-28T18:49:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Johannes Schindelin schrieb:\n> ...\n>>> Recently there was a report that \\n in the substitution side of s/// is not\n>>> supported by all seds :-(\n>>\n>> Okay, how about replacing the line with\n>>\n>> +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\\n>> +export GIT_'$uid'_NAME/p\n>>\n>> Hmm? (It works here.)\n>\n> This looks good. The other case I'm refering to was also solved in this way.\n\nThat looks ugly to me.\n\nIs there a particular reason to force linebreak when a semicolon would\ndo?\n"},{"id":"61273","messageId":"Pine.LNX.4.64.0711281903330.27959@racer.site","threadId":"11022","inReplyTo":"7vr6ia5hoi.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T19:03:52Z","receivedAt":"2007-11-28T19:03:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Sixt writes:\n> \n> > Johannes Schindelin schrieb:\n> > ...\n> >>> Recently there was a report that \\n in the substitution side of s/// is not\n> >>> supported by all seds :-(\n> >>\n> >> Okay, how about replacing the line with\n> >>\n> >> +\t\t\ts/.*/GIT_'$uid'_NAME='\\''&'\\''\\\n> >> +export GIT_'$uid'_NAME/p\n> >>\n> >> Hmm? (It works here.)\n> >\n> > This looks good. The other case I'm refering to was also solved in this way.\n> \n> That looks ugly to me.\n> \n> Is there a particular reason to force linebreak when a semicolon would\n> do?\n\nD'oh. Of course. You want me to resend?\n\nCiao,\nDscho\n"},{"id":"61309","messageId":"7vzlwy2dkm.fsf@gitster.siamese.dyndns.org","threadId":"11022","inReplyTo":"85ve7m8iix.fsf@lola.goethe.zz","subject":"Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T22:46:33Z","receivedAt":"2007-11-28T22:46:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> Johannes Schindelin writes:\n>\n>> It might be POSIX, but there are shells that do not like the\n>> expression 'export VAR=VAL'.\n>\n> As long as we have no positive report about any such shell that\n> _otherwise_ would be usable for git, why bother?\n\nI thought somebody already mention that ash mishandles \"export VAR=VAL\"\nbut otherwise Ok.\n"},{"id":"61311","messageId":"7vve7m2dhs.fsf@gitster.siamese.dyndns.org","threadId":"11022","inReplyTo":"Pine.LNX.4.64.0711281903330.27959@racer.site","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T22:48:15Z","receivedAt":"2007-11-28T22:48:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Is there a particular reason to force linebreak when a semicolon would\n>> do?\n>\n> D'oh. Of course. You want me to resend?\n\nSemicolon I can handle but you seem to have local changes to filter\nbranch.\n"},{"id":"61314","messageId":"85sl2q6kyu.fsf@lola.goethe.zz","threadId":"11022","inReplyTo":"7vzlwy2dkm.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-28T22:53:13Z","receivedAt":"2007-11-28T22:53:13Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> David Kastrup writes:\n>\n>> Johannes Schindelin writes:\n>>\n>>> It might be POSIX, but there are shells that do not like the\n>>> expression 'export VAR=VAL'.\n>>\n>> As long as we have no positive report about any such shell that\n>> _otherwise_ would be usable for git, why bother?\n>\n> I thought somebody already mention that ash mishandles \"export VAR=VAL\"\n> but otherwise Ok.\n\ndak@lola:~$ ash\n$ export JUNK=woozle\n$ sh -c 'echo $JUNK'\nwoozle\n$ exit\ndak@lola:~$ dash\n$ export JUNK=woozle\n$ sh -c 'echo $JUNK'\nwoozle\n$ exit\n\nWhat problem are we talking about exactly, and with what shell?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"61316","messageId":"20071128230203.GA13964@coredump.intra.peff.net","threadId":"11022","inReplyTo":"85sl2q6kyu.fsf@lola.goethe.zz","subject":"Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-28T23:02:03Z","receivedAt":"2007-11-28T23:02:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 28, 2007 at 11:53:13PM +0100, David Kastrup wrote:\n\n> dak@lola:~$ ash\n> $ export JUNK=woozle\n> $ sh -c 'echo $JUNK'\n> woozle\n> $ exit\n> dak@lola:~$ dash\n> $ export JUNK=woozle\n> $ sh -c 'echo $JUNK'\n> woozle\n> $ exit\n> \n> What problem are we talking about exactly, and with what shell?\n\n$ uname -sr\nFreeBSD 6.1-RELEASE-p17-jc1\n$ /bin/sh\n$ FOO='with spaces'\n$ echo $FOO\nwith spaces\n$ OK=$FOO; export OK\n$ sh -c 'echo $OK'\nwith spaces\n$ export BAD=$FOO\n$ sh -c 'echo $BAD'\nwith\n$ echo $BAD\nwith\n\n-Peff\n"},{"id":"61318","messageId":"Pine.LNX.4.64.0711282304360.27959@racer.site","threadId":"11022","inReplyTo":"7vzlwy2dkm.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T23:05:54Z","receivedAt":"2007-11-28T23:05:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Junio C Hamano wrote:\n\n> > Johannes Schindelin writes:\n> >\n> >> It might be POSIX, but there are shells that do not like the\n> >> expression 'export VAR=VAL'.\n> >\n> > As long as we have no positive report about any such shell that\n> > _otherwise_ would be usable for git, why bother?\n> \n> I thought somebody already mention that ash mishandles \"export VAR=VAL\"\n> but otherwise Ok.\n\nI thought I read an implicit request from you. And yes, there was an \nincidental bugfix in quiltimport.\n\nBesides, this \"why bother?\" sounds awfully like \"it's in POSIX and I \nignore the experience of Junio who knows that there are/were reasons not \nto use export VAR=VAL\" to me. After all, I read this often enough on this \nlist, and just forgot to fix it in filter-branch before submitting the \npatch.\n\nCiao,\nDscho\n"},{"id":"61319","messageId":"Pine.LNX.4.64.0711282307360.27959@racer.site","threadId":"11022","inReplyTo":"7vve7m2dhs.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T23:08:32Z","receivedAt":"2007-11-28T23:08:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> Is there a particular reason to force linebreak when a semicolon would\n> >> do?\n> >\n> > D'oh. Of course. You want me to resend?\n> \n> Semicolon I can handle but you seem to have local changes to filter\n> branch.\n\nOnly that patch to de-uglify the functions in the commit filter that I \nsent out earlier.\n\nCiao,\nDscho\n"},{"id":"61320","messageId":"85mysy6k5x.fsf@lola.goethe.zz","threadId":"11022","inReplyTo":"20071128230203.GA13964@coredump.intra.peff.net","subject":"Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-28T23:10:34Z","receivedAt":"2007-11-28T23:10:34Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King writes:\n\n> On Wed, Nov 28, 2007 at 11:53:13PM +0100, David Kastrup wrote:\n>\n>> dak@lola:~$ ash\n>> $ export JUNK=woozle\n>> $ sh -c 'echo $JUNK'\n>> woozle\n>> $ exit\n>> dak@lola:~$ dash\n>> $ export JUNK=woozle\n>> $ sh -c 'echo $JUNK'\n>> woozle\n>> $ exit\n>> \n>> What problem are we talking about exactly, and with what shell?\n>\n> $ uname -sr\n> FreeBSD 6.1-RELEASE-p17-jc1\n> $ /bin/sh\n> $ FOO='with spaces'\n> $ echo $FOO\n> with spaces\n> $ OK=$FOO; export OK\n> $ sh -c 'echo $OK'\n> with spaces\n> $ export BAD=$FOO\n> $ sh -c 'echo $BAD'\n> with\n> $ echo $BAD\n> with\n\nI'd write\nexport BAD=\"$FOO\"\nanyhow. And also OK=\"$FOO\" by the way. The alternatives scare me.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"61372","messageId":"474E6CC8.8000301@viscovery.net","threadId":"11022","inReplyTo":"85sl2q6kyu.fsf@lola.goethe.zz","subject":"Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-29T07:39:52Z","receivedAt":"2007-11-29T07:39:52Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"David Kastrup schrieb:\n> Junio C Hamano writes:\n>> I thought somebody already mention that ash mishandles \"export VAR=VAL\"\n>> but otherwise Ok.\n> \n> dak@lola:~$ ash\n> $ export JUNK=woozle\n> $ sh -c 'echo $JUNK'\n> woozle\n> $ exit\n> dak@lola:~$ dash\n> $ export JUNK=woozle\n> $ sh -c 'echo $JUNK'\n> woozle\n> $ exit\n> \n> What problem are we talking about exactly, and with what shell?\n\n$ export foo=\"bar baz\"\n$ bash\nbash$ export JUNK=$foo\nbash$ sh -c 'echo \"$JUNK\"'\nbar baz\nbash$ exit\nexit\n$ ash\nash$ export JUNK=$foo\nash$ sh -c 'echo \"$JUNK\"'\nbar\nash$ exit\n\nThe problem is $foo not being quoted on the RHS of the assignment of the \nexport command: bash doesn't word-split, but ash does. Hence, *if*\nexport VAR=VAL is used, always quote VAL.\n\n-- Hannes\n"},{"id":"61386","messageId":"85prxt5p9k.fsf@lola.goethe.zz","threadId":"11022","inReplyTo":"474E6CC8.8000301@viscovery.net","subject":"Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-29T10:17:59Z","receivedAt":"2007-11-29T10:17:59Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Sixt writes:\n\n>> What problem are we talking about exactly, and with what shell?\n>\n> $ export foo=\"bar baz\"\n> $ bash\n> bash$ export JUNK=$foo\n> bash$ sh -c 'echo \"$JUNK\"'\n> bar baz\n> bash$ exit\n> exit\n> $ ash\n> ash$ export JUNK=$foo\n> ash$ sh -c 'echo \"$JUNK\"'\n> bar\n> ash$ exit\n>\n> The problem is $foo not being quoted on the RHS of the assignment of\n> the export command: bash doesn't word-split, but ash does. Hence, *if*\n> export VAR=VAL is used, always quote VAL.\n\nI much prefer the quoting solution over the quite more invasive rewrites\nproposed here.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"}]}