Re: [PATCH] sequencer: pass absolute GIT_WORK_TREE to exec commands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 13, 2018 at 08:57:03PM -0400, Jeff King wrote:
> On Sat, Jul 14, 2018 at 12:35:05AM +0000, brian m. carlson wrote:
> 
> > diff --git a/sequencer.c b/sequencer.c
> > index 5354d4d51e..c8e16f9168 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -2636,6 +2636,8 @@ static int do_exec(const char *command_line)
> >  	fprintf(stderr, "Executing: %s\n", command_line);
> >  	child_argv[0] = command_line;
> >  	argv_array_pushf(&child_env, "GIT_DIR=%s", absolute_path(get_git_dir()));
> > +	argv_array_pushf(&child_env, "GIT_WORK_TREE=%s",
> > +			 absolute_path(get_git_work_tree()));
> >  	status = run_command_v_opt_cd_env(child_argv, RUN_USING_SHELL, NULL,
> >  					  child_env.argv);
> >  
> 
> As a general rule of "always pass GIT_WORK_TREE with GIT_DIR", you have
> to deal with the case where there _isn't_ a work tree. Are we OK here
> because this code is inside sequencer.c, and you cannot do a sequencer
> operation without a work tree?

I believe that's correct.  We only call this code path from
sequencer_pick_commits or sequencer_continue, and those code paths are
only called from revert, commit, and rebase--helper; all of those
require a working tree.

> So I think it would also work to set:
> 
>   GIT_IMPLICIT_WORK_TREE=0
> 
> here. But if the answer to my "are we OK" above is yes, I am fine with
> either that solution or the one you show here (but I think the commit
> message should probably mention it).

I'll reroll with a mention of that in the commit message.  Thanks for a
careful review.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux