{"thread":{"id":"29810","subject":"[RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris","startedAt":"2012-03-02T09:13:00Z","lastAt":"2012-03-09T21:59:06Z","messageCount":12,"participants":["Stefano Lattarini","Thomas Rast","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"185894","messageId":"df98ed215324f521f3aaff7fa4ba41ba2a1894dc.1330679536.git.stefano.lattarini@gmail.com","threadId":"29810","inReplyTo":null,"subject":"[RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2012-03-02T09:13:00Z","receivedAt":"2012-03-02T09:13:00Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On a Solaris 10 system with Solaris XPG4 make installed as /usr/xpg4/bin/make,\nGNU make installed as /usr/local/bin/make, and with /usr/local/bin appearing\nin $PATH *before* /usr/xpg4/bin, I was seeing errors like this upon invoking\n\"make all\":\n\n SUBDIR perl\n make: Warning: Ignoring DistributedMake -o option\n Usage : make [ -f makefile ][ -K statefile ]...\n make: Fatal error: Unknown option `-C'\n\nThis happens because the Git's Makefiles, when running on Solaris, sanitize\n$PATH by prepending /usr/xpg6/bin and /usr/xpg4/bin to it, but in the setup\ndescribed above such a behaviour has the unintended consequence of forcing\nthe use of Solaris make in recursive make invocations, even if the $(MAKE)\nmacro is being correctly used in them; this happens because, in that setup,\nthe original GNU make process was invoked simply as \"make\".\n\nTo avoid such an issue, we instruct our Makefile to redefine $(MAKE) to\npoint to the absolute path of the originally-invoked make program.\n---\n\n The implementation is still rough and not completely portable, but before\n investing more time in refining it I'd like to know if you gitsters think\n the idea behind it is sound.\n\n Regards,\n Stefano\n\n Makefile | 13 +++++++++++++\n 1 files changed, 13 insertions(+), 0 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex e4f8e0e..8cba6e8 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -303,6 +303,19 @@ ifdef MSVC\n \tuname_O := Windows\n endif\n \n+# This Makefile will possibly sanitize PATH by prepending system-specific\n+# directories to it (e.g., /usr/xpg4/bin on Solaris). This can become\n+# problematic for recursive make invocations, if one of those directories\n+# contains a \"make\" program and the user has called GNU make by simply\n+# invoking \"make\" (this can happen e.g. when GNU make has been installed\n+# as /usr/local/bin/make). To avoid such issues, we redefine $(MAKE) to\n+# point to the absolute path of the originally-invoked make program.\n+# FIXME: this is ugly, and which(1) is quite unportable. Find a better\n+# \t way to obtain the same effect.\n+MAKE := $(shell set $(MAKE); m1=$$1; shift; \\\n+ m2=`which $$m1 2>/dev/null` && test -n \"$$m2\" || m2=$$m1; \\\n+ echo \"$$m2 $$*\")\n+\n # CFLAGS and LDFLAGS are for the users to override from the command line.\n \n CFLAGS = -g -O2 -Wall\n-- \n1.7.9\n"},{"id":"185897","messageId":"87obsfcpnc.fsf@thomas.inf.ethz.ch","threadId":"29810","inReplyTo":"df98ed215324f521f3aaff7fa4ba41ba2a1894dc.1330679536.git.stefano.lattarini@gmail.com","subject":"Re: [RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2012-03-02T09:34:31Z","receivedAt":"2012-03-02T09:34:31Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Stefano Lattarini writes:\n\n> +# FIXME: this is ugly, and which(1) is quite unportable. Find a better\n> +# \t way to obtain the same effect.\n> +MAKE := $(shell set $(MAKE); m1=$$1; shift; \\\n> + m2=`which $$m1 2>/dev/null` && test -n \"$$m2\" || m2=$$m1; \\\n> + echo \"$$m2 $$*\")\n\nThere's 'command -v make'. 'man 1p command' on my system (opensuse\ninstalls a bunch of POSIX reference material) says\n\n -v (On systems supporting the User Portability Utilities\n option.) Write a string to standard output that indicates\n the pathname or command that will be used by the shell, in\n the current shell execution environment (see Shell Execu-\n tion Environment ), to invoke command_name, but do not\n invoke command_name.\n\n * Utilities, regular built-in utilities, command_names\n including a slash character, and any implementation-\n defined functions that are found using the PATH vari-\n able (as described in Command Search and Execution ),\n shall be written as absolute pathnames.\n\nSo perhaps enough systems including Solaris \"support the User\nPortability Utilities option\", and you can use this?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"185898","messageId":"4F5095D6.6050401@gmail.com","threadId":"29810","inReplyTo":"87obsfcpnc.fsf@thomas.inf.ethz.ch","subject":"Re: [RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2012-03-02T09:41:42Z","receivedAt":"2012-03-02T09:41:42Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On 03/02/2012 10:34 AM, Thomas Rast wrote:\n> Stefano Lattarini writes:\n> \n>> +# FIXME: this is ugly, and which(1) is quite unportable. Find a better\n>> +# \t way to obtain the same effect.\n>> +MAKE := $(shell set $(MAKE); m1=$$1; shift; \\\n>> + m2=`which $$m1 2>/dev/null` && test -n \"$$m2\" || m2=$$m1; \\\n>> + echo \"$$m2 $$*\")\n> \n> There's 'command -v make'. 'man 1p command' on my system (opensuse\n> installs a bunch of POSIX reference material) says\n> \n> -v (On systems supporting the User Portability Utilities\n> option.) Write a string to standard output that indicates\n> the pathname or command that will be used by the shell, in\n> the current shell execution environment (see Shell Execu-\n> tion Environment ), to invoke command_name, but do not\n> invoke command_name.\n> \n> * Utilities, regular built-in utilities, command_names\n> including a slash character, and any implementation-\n> defined functions that are found using the PATH vari-\n> able (as described in Command Search and Execution ),\n> shall be written as absolute pathnames.\n> \n> So perhaps enough systems including Solaris \"support the User\n> Portability Utilities option\", and you can use this?\n> \nThanks, I had completely forgotten about this \"trick\". It works correctly\nwith both /bin/sh and /bin/ksh on all of NetBSD 5.1, OpenBSD 5.0 and\nSolaris 10, as well as with bash (4.1.5) and dash (0.5.5.1) on my Debian\nunstable. I will post an updated patch later today (or this evening).\n\nRegards,\n Stefano\n"},{"id":"185899","messageId":"abe2c43575849e612b17a1e6a6f8eb33db9623b8.1330683426.git.stefano.lattarini@gmail.com","threadId":"29810","inReplyTo":"4F5095D6.6050401@gmail.com","subject":"[PATCH v2] build: avoid possible confusion between GNU/XPG4 make on Solaris","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2012-03-02T10:18:24Z","receivedAt":"2012-03-02T10:18:24Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On a Solaris 10 system with Solaris XPG4 make installed as /usr/xpg4/bin/make,\nGNU make installed as /usr/local/bin/make, and with /usr/local/bin appearing\nin $PATH *before* /usr/xpg4/bin, I was seeing errors like this upon invoking\n\"make all\":\n\n SUBDIR perl\n make: Warning: Ignoring DistributedMake -o option\n Usage : make [ -f makefile ][ -K statefile ]...\n make: Fatal error: Unknown option `-C'\n\nThis happens because the Git's Makefiles, when running on Solaris, sanitize\n$PATH by prepending /usr/xpg6/bin and /usr/xpg4/bin to it, but in the setup\ndescribed above such a behaviour has the unintended consequence of forcing\nthe use of Solaris make in recursive make invocations, even if the $(MAKE)\nmacro is being correctly used in them; this happens because, in that setup,\nthe original GNU make process was invoked simply as \"make\".\n\nTo avoid such an issue, we instruct our Makefile to redefine $(MAKE) to\npoint to the absolute path of the originally-invoked make program.\n\nHelped-by: Thomas Rast \nSigned-off-by: Stefano Lattarini \n---\n Makefile | 15 +++++++++++++++\n 1 files changed, 15 insertions(+), 0 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex e4f8e0e..e71d688 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -303,6 +303,21 @@ ifdef MSVC\n \tuname_O := Windows\n endif\n \n+# This Makefile will possibly sanitize PATH by prepending system-specific\n+# directories to it (e.g., /usr/xpg4/bin on Solaris). This can become\n+# problematic for recursive make invocations, if one of those directories\n+# contains a \"make\" program and the user has called GNU make by simply\n+# invoking \"make\" (this can happen e.g. when GNU make has been installed\n+# as /usr/local/bin/make). To avoid such issues, we redefine $(MAKE) to\n+# point to the absolute path of the originally-invoked make program.\n+original_MAKE := $(MAKE)\n+MAKE := $(shell command -v $(firstword $(original_MAKE)) 2>/dev/null)\n+ifeq ($(MAKE),)\n+\tMAKE := $(original_MAKE)\n+else\n+\tMAKE += $(wordlist 2,$(words $(original_MAKE)),$(original_MAKE))\n+endif\n+\n # CFLAGS and LDFLAGS are for the users to override from the command line.\n \n CFLAGS = -g -O2 -Wall\n-- \n1.7.9\n"},{"id":"185935","messageId":"7vhay6etqc.fsf@alter.siamese.dyndns.org","threadId":"29810","inReplyTo":"df98ed215324f521f3aaff7fa4ba41ba2a1894dc.1330679536.git.stefano.lattarini@gmail.com","subject":"Re: [RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-02T18:35:39Z","receivedAt":"2012-03-02T18:35:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefano Lattarini writes:\n\n> On a Solaris 10 system with Solaris XPG4 make installed as /usr/xpg4/bin/make,\n> GNU make installed as /usr/local/bin/make, and with /usr/local/bin appearing\n> in $PATH *before* /usr/xpg4/bin, I was seeing errors like this upon invoking\n> \"make all\":\n\nAfter reading this explanation, my first reaction is that the prefixing of\npath _is_ what is wrong. The prefixing is done to help a subset of\nSolaris users who are unaware of /usr/xpg4/bin that are more POSIX than\nwhat they have in /usr/bin, and that is what is hurting people like you\nwho know what you are doing and have suitable tools in other places, like\nyou do in /usr/local/bin.\n\nAnd the real fix for your problem is _not_ an ugly override of $(MAKE)\nlike you do in this patch, I think. After all, somebody else who have a\ntool in /usr/local/bin that is saner than what is in /usr/xpg4/bin may\nsuffer from the same issue for commands other than \"make\".\n\nSo the real solution would probably be to let you override how the\nBROKEN_PATH_FIX works, no?\n\nAh... and I think we already have such a solution in our Makefile. Can't\nyou override SANE_TOOL_PATH in your config.mak instead?\n\n> +# This Makefile will possibly sanitize PATH by prepending system-specific\n> +# directories to it (e.g., /usr/xpg4/bin on Solaris). This can become\n> +# problematic for recursive make invocations, if one of those directories\n> +# contains a \"make\" program and the user has called GNU make by simply\n> +# invoking \"make\" (this can happen e.g. when GNU make has been installed\n> +# as /usr/local/bin/make). To avoid such issues, we redefine $(MAKE) to\n> +# point to the absolute path of the originally-invoked make program.\n> +# FIXME: this is ugly, and which(1) is quite unportable. Find a better\n> +# \t way to obtain the same effect.\n> +MAKE := $(shell set $(MAKE); m1=$$1; shift; \\\n> + m2=`which $$m1 2>/dev/null` && test -n \"$$m2\" || m2=$$m1; \\\n> + echo \"$$m2 $$*\")\n> +\n> # CFLAGS and LDFLAGS are for the users to override from the command line.\n> \n> CFLAGS = -g -O2 -Wall\n"},{"id":"185942","messageId":"4F5118CF.6030402@gmail.com","threadId":"29810","inReplyTo":"7vhay6etqc.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2012-03-02T19:00:31Z","receivedAt":"2012-03-02T19:00:31Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On 03/02/2012 07:35 PM, Junio C Hamano wrote:\n> Stefano Lattarini writes:\n> \n>> On a Solaris 10 system with Solaris XPG4 make installed as /usr/xpg4/bin/make,\n>> GNU make installed as /usr/local/bin/make, and with /usr/local/bin appearing\n>> in $PATH *before* /usr/xpg4/bin, I was seeing errors like this upon invoking\n>> \"make all\":\n> \n> After reading this explanation, my first reaction is that the prefixing of\n> path _is_ what is wrong. The prefixing is done to help a subset of\n> Solaris users who are unaware of /usr/xpg4/bin that are more POSIX than\n> what they have in /usr/bin, and that is what is hurting people like you\n> who know what you are doing and have suitable tools in other places, like\n> you do in /usr/local/bin.\n> \n> And the real fix for your problem is _not_ an ugly override of $(MAKE)\n> like you do in this patch, I think. After all, somebody else who have a\n> tool in /usr/local/bin that is saner than what is in /usr/xpg4/bin may\n> suffer from the same issue for commands other than \"make\".\n> \n> So the real solution would probably be to let you override how the\n> BROKEN_PATH_FIX works, no?\n> \n> Ah... and I think we already have such a solution in our Makefile. Can't\n> you override SANE_TOOL_PATH in your config.mak instead?\n>\nYes and no. While in hindsight I agree that using this already-provided\nsolution is much better than my ugly automatic munging of $(MAKE) (so yes,\nlet's scrap the present patch), I also think that if one is setting up the\nconfiguration of the Git tree using the the autoconf-generated configure\nscript (as I do), he wants configure to Do The Right Thing automatically\nin this regard too -- thus recognizing that /usr/xpg4/bin is already in\n$PATH before /bin and /usr/bin, and setting up an appropriate default for\nSANE_TOOL_PATH in 'config.make.autogen' accordingly.\n\nWhat would you think of a patch in this direction?\n\nThanks,\n Stefano\n"},{"id":"185946","messageId":"7vfwdqdbv0.fsf@alter.siamese.dyndns.org","threadId":"29810","inReplyTo":"4F5118CF.6030402@gmail.com","subject":"Re: [RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-02T19:46:59Z","receivedAt":"2012-03-02T19:46:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefano Lattarini writes:\n\n> configuration of the Git tree using the the autoconf-generated configure\n> script (as I do), he wants configure to Do The Right Thing automatically\n> in this regard too\n> $PATH before /bin and /usr/bin, and setting up an appropriate default for\n> SANE_TOOL_PATH in 'config.make.autogen' accordingly.\n>\n> What would you think of a patch in this direction?\n\nYeah, that was exactly what I was suggesting, but it may not have been\nobvious.\n\nAs I consider autoconf merely a secondary mechanism to set config.mak,\nwhenever I say \"that is solved by local tweak in config.mak\", letting\n./configure to do that tweak automatically is already covered by that\nsuggestion.\n"},{"id":"186561","messageId":"a706eaa1e1cd5e13a8cd98362fe09bba628789d1.1331296220.git.stefano.lattarini@gmail.com","threadId":"29810","inReplyTo":"7vhay6etqc.fsf@alter.siamese.dyndns.org","subject":"[PATCH] configure: allow user to prevent $PATH \"sanitization\" on Solaris","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2012-03-09T12:43:55Z","receivedAt":"2012-03-09T12:43:55Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On a Solaris 10 system with Solaris make installed as '/usr/xpg4/bin/make',\nGNU make installed as '/usr/local/bin/make', and with '/usr/local/bin'\nappearing in $PATH *before* '/usr/xpg4/bin', I was seeing errors like this\nupon invoking \"make all\":\n\n SUBDIR perl\n make: Warning: Ignoring DistributedMake -o option\n Usage : make [ -f makefile ][ -K statefile ]...\n make: Fatal error: Unknown option `-C'\n\nThis happened because the Git's Makefile, when running on Solaris,\nautomatically \"sanitizes\" $PATH by prepending '/usr/xpg6/bin' and\n'/usr/xpg4/bin' to it, and in the setup described above such a behaviour\nhas the unintended consequence of forcing the use of Solaris make\nin recursive make invocations -- even if the $(MAKE) macro is being\ncorrectly used in them!\n\nFor developers that don't use the autoconf machinery, the best and easier\nfix in such a situation is to properly override $(SANE_TOOL_PATH) in\nconfig.mak. But a developer using the autoconf-generated configure script\nto set up its Git source tree's configuration wouldn't expect to also have\nto provide such an override *by hand* after having run configure; he would\neither expect:\n\n 1) that the issue is automatically detected and transparently worked\n around by configure; or at least\n\n 2) that a configure-time override telling how (and if) PATH is to be\n sanitized is provided.\n\nThis change implements the second approach, which is less-ambitious but\nalso much less fragile. Note that, even if we should decide to implement\nthe first approach in the future, the code added by the present change\nstill be useful, allowing the user the possibility to override the\nconfigure's choices in case they turn out wrong (in true autotools\nspirit).\n---\n\n Hi Junio, sorry for the delay. Here is a simpler approach that worked\n out well enough for me; the commit message should explain the rationales\n and motivations for it in detail.\n\n Regards,\n Stefano\n\n configure.ac | 17 +++++++++++++++++\n 1 files changed, 17 insertions(+), 0 deletions(-)\n\ndiff --git a/configure.ac b/configure.ac\nindex 8bb0f44..72f7958 100644\n--- a/configure.ac\n+++ b/configure.ac\n@@ -137,6 +137,23 @@ if test -n \"$1\"; then\n fi\n ])\n \n+# Directories holding \"saner\" versions of common or POSIX binaries.\n+AC_ARG_WITH([sane-tool-path],\n+ [AS_HELP_STRING(\n+ [--with-sane-tool-path=DIR-1[[:DIR-2...:DIR-n]]],\n+ [Directories to prepend to PATH in build system and generated scripts])],\n+ [if test \"$withval\" = \"no\"; then\n+ withval=''\n+ else\n+ AC_MSG_NOTICE([Setting SANE_TOOL_PATH to '$withval'])\n+ fi\n+ GIT_CONF_APPEND_LINE([SANE_TOOL_PATH=$withval])],\n+ [# If the \"--with-sane-tool-path\" option was not given, don't touch\n+ # SANE_TOOL_PATH here, but let defaults in Makefile take care of it.\n+ # This should minimize spurious differences in the behaviour of the\n+ # Git build system when configure is used w.r.t. when it is not.\n+ :])\n+\n ## Site configuration related to programs (before tests)\n ## --with-PACKAGE[=ARG] and --without-PACKAGE\n #\n-- \n1.7.9\n"},{"id":"186572","messageId":"7vboo57n6c.fsf@alter.siamese.dyndns.org","threadId":"29810","inReplyTo":"a706eaa1e1cd5e13a8cd98362fe09bba628789d1.1331296220.git.stefano.lattarini@gmail.com","subject":"Re: [PATCH] configure: allow user to prevent $PATH \"sanitization\" on Solaris","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T16:29:31Z","receivedAt":"2012-03-09T16:29:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefano Lattarini writes:\n\n> Hi Junio, sorry for the delay.\n\nThanks for not forgetting.\n\nThe contributors are used as \"tracking system\" around here, and they\nwon't get \"what happened to your stalled patch? Any progress?\" from\nanybody (unless there are others who are deeply interested in the\ntopic). Delay is not a problem.\n"},{"id":"186583","messageId":"7vaa3p5zht.fsf@alter.siamese.dyndns.org","threadId":"29810","inReplyTo":"a706eaa1e1cd5e13a8cd98362fe09bba628789d1.1331296220.git.stefano.lattarini@gmail.com","subject":"Re: [PATCH] configure: allow user to prevent $PATH \"sanitization\" on Solaris","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T19:46:22Z","receivedAt":"2012-03-09T19:46:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefano Lattarini writes:\n\n> This change implements the second approach, which is less-ambitious but\n> also much less fragile.\n\nI personally think your second one is the only sane option.\n\n> ---\n\nYou forgot to sign-off the patch, perhaps?\n"},{"id":"186586","messageId":"4F5A7A34.3050000@gmail.com","threadId":"29810","inReplyTo":"7vaa3p5zht.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] configure: allow user to prevent $PATH \"sanitization\" on Solaris","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2012-03-09T21:46:28Z","receivedAt":"2012-03-09T21:46:28Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On 03/09/2012 08:46 PM, Junio C Hamano wrote:\n> Stefano Lattarini writes:\n> \n>> This change implements the second approach, which is less-ambitious but\n>> also much less fragile.\n> \n> I personally think your second one is the only sane option.\n> \n>> ---\n> \n> You forgot to sign-off the patch, perhaps?\n>\nIndeed (but I've now fixed my git aliases to avoid similar issues in\nthe future). Will you fix the issue locally, or should I re-roll?\n\nThanks, and sorry for the noise,\n Stefano\n"},{"id":"186587","messageId":"7vty1x4es5.fsf@alter.siamese.dyndns.org","threadId":"29810","inReplyTo":"4F5A7A34.3050000@gmail.com","subject":"Re: [PATCH] configure: allow user to prevent $PATH \"sanitization\" on Solaris","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T21:59:06Z","receivedAt":"2012-03-09T21:59:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefano Lattarini writes:\n\n> On 03/09/2012 08:46 PM, Junio C Hamano wrote:\n>> Stefano Lattarini writes:\n>> \n>>> This change implements the second approach, which is less-ambitious but\n>>> also much less fragile.\n>> \n>> I personally think your second one is the only sane option.\n>> \n>>> ---\n>> \n>> You forgot to sign-off the patch, perhaps?\n>>\n> Indeed (but I've now fixed my git aliases to avoid similar issues in\n> the future). Will you fix the issue locally, or should I re-roll?\n\nSure, I'll fix it up. Thanks.\n"}]}