Re: [RFC/PATCH v2 2/3] run-command: make sure hooks have always GIT_DIR

2014-04-23 Thread Felipe Contreras
Junio C Hamano wrote:
> Felipe Contreras  writes:
> 
> > Signed-off-by: Felipe Contreras 
> 
> Why is this a good change?

When a hook is called from a command without NEED_WORK_TREE, GIT_DIR is not set
(e.g. git branch).

> How does it prevent existing hook scripts from suddenly start
> misbehaving, where they do *not* expect to see an explicit GIT_DIR
> pointing at the original repository hook gets run in exported into
> their environment?

Fine, I'll use "${GIT_DIR-.git}" in my hook tests.

> For example, one of my post-receive hooks in a repository I push into records
> $cwd (which is the GIT_DIR of receiving repository), chdir's to another
> repository and then executes "git pull $cwd" from there, and that relies on
> the fact that being at the top-level of that other repository without GIT_DIR
> environment pointing at elsewhere but having .git directory in that top-level
> repository is sufficient to kick the auto-discovery of the repository that
> receives the "pull" in order to work correctly.

Let's hope post-receive is never called from a command that has NEED_WORK_TREE 
then.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC/PATCH v2 2/3] run-command: make sure hooks have always GIT_DIR

2014-04-23 Thread Junio C Hamano
Felipe Contreras  writes:

> Signed-off-by: Felipe Contreras 

Why is this a good change?  From a zero-line log message, I cannot
even tell if this is trying to fix some problem, or trying to give
new capabilities to hooks.

How does it prevent existing hook scripts from suddenly start
misbehaving, where they do *not* expect to see an explicit GIT_DIR
pointing at the original repository hook gets run in exported into
their environment?  For example, one of my post-receive hooks in a
repository I push into records $cwd (which is the GIT_DIR of
receiving repository), chdir's to another repository and then
executes "git pull $cwd" from there, and that relies on the fact
that being at the top-level of that other repository without GIT_DIR
environment pointing at elsewhere but having .git directory in that
top-level repository is sufficient to kick the auto-discovery of the
repository that receives the "pull" in order to work correctly.



> ---
>  run-command.c | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/run-command.c b/run-command.c
> index 75abc47..8e188f6 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -765,12 +765,29 @@ int run_hook_ve(const char *const *env, const char 
> *name, va_list args)
>   struct child_process hook;
>   struct argv_array argv = ARGV_ARRAY_INIT;
>   const char *p;
> - int ret;
> + const char **mod_env = NULL;
> + int ret, i = 0;
> + struct strbuf buf = STRBUF_INIT;
>  
>   p = find_hook(name);
>   if (!p)
>   return 0;
>  
> + if (!getenv(GIT_DIR_ENVIRONMENT)) {
> + if (env)
> + for (i = 0; env[i]; i++);
> +
> + mod_env = xcalloc(i + 2, sizeof(*mod_env));
> +
> + if (env)
> + for (i = 0; env[i]; i++)
> + mod_env[i] = env[i];
> +
> + strbuf_addf(&buf, "GIT_DIR=%s", get_git_dir());
> + mod_env[i++] = buf.buf;
> + mod_env[i++] = NULL;
> + }
> +
>   argv_array_push(&argv, p);
>  
>   while ((p = va_arg(args, const char *)))
> @@ -778,12 +795,15 @@ int run_hook_ve(const char *const *env, const char 
> *name, va_list args)
>  
>   memset(&hook, 0, sizeof(hook));
>   hook.argv = argv.argv;
> - hook.env = env;
> + hook.env = mod_env ? mod_env : env;
>   hook.no_stdin = 1;
>   hook.stdout_to_stderr = 1;
>  
>   ret = run_command(&hook);
>   argv_array_clear(&argv);
> + strbuf_release(&buf);
> + free(mod_env);
> +
>   return ret;
>  }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html