From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: Chris Packham <judge.packham@gmail.com>
Cc: git@vger.kernel.org, Jens.Lehmann@web.de, gitster@pobox.com
Subject: Re: [RFC/PATCHv2 5/5] grep: add support for grepping in submodules
Date: Mon, 18 Oct 2010 10:37:01 +0700 [thread overview]
Message-ID: <AANLkTikUpUZrwj9S91ZarUbfkcPgpnyx3h54dJb2W9X0@mail.gmail.com> (raw)
In-Reply-To: <4CBBAA8F.2040805@gmail.com>
On Mon, Oct 18, 2010 at 9:01 AM, Chris Packham <judge.packham@gmail.com> wrote:
> On 17/10/10 03:28, Nguyen Thai Ngoc Duy wrote:
>> On Sat, Oct 16, 2010 at 6:26 AM, Chris Packham <judge.packham@gmail.com> wrote:
>>> +static int grep_submodule(struct grep_opt *opt, const char *path,
>>> + const char *sha1, const char *tree_name)
>>> +{
>>> + struct strbuf buf = STRBUF_INIT;
>>> + struct strbuf pre_buf = STRBUF_INIT;
>>> + struct child_process cp;
>>> + const char **argv = create_sub_grep_argv(opt, path, sha1, tree_name);
>>
>> Can we just save sha1 in a env variable and drop this argv rewrite?
>>
> The tree_name is a hangover from when I was passing it as a command line
> arg, I'll remove it. For now we still need to rewrite argv to modify the
> pathspec and max-depth, eventually I'd like to ditch that approach in
> favour of using fork() and modifying opts.
You would also need to undo git repo setup, i.e. resetting static
variables in environment.c and setup.c, maybe some more. Also fork()
is not available on Windows.
Spawning new processes is the only feasible way I can think of now (or
even in the next year).
>>> + const char *git_dir;
>>> + int hit = 0;
>>> + memset(&cp, 0, sizeof(cp));
>>> +
>>> + strbuf_addf(&buf, "%s/.git", path);
>>> + git_dir = read_gitfile_gently(buf.buf);
>>> + if (!git_dir)
>>> + git_dir = buf.buf;
>>> + if (!is_directory(git_dir))
>>> + goto out_free;
>>> +
>>> + setenv("GIT_SUPER_REFNAME", tree_name, 1);
>>> + setenv(GIT_DIR_ENVIRONMENT, git_dir, 1);
>>> + setenv(GIT_WORK_TREE_ENVIRONMENT, path, 1);
>>
>> cp.env can be used to set these variables
>>
> I was struggling a little with how to do this. The run_command
> invocation in submodules.c uses local_repo_env which is protected
> against modification. I also don't understand how the actual values are
> passed. If someone could point me in the right direction it'd be
> appreciated.
From what I read in run-command.c,the current env var set is copied
as-is for new process, then any new variables from cp.env will be
added. Old variables can also be unset by saying "VARIABLE=" in
cp.env. The final env var set will be used for new process. Current
env vars are untouched. Something like this should work:
const char *env[4];
env[0] = malloc_sprintf("GIT_SUPER_REFNAME=%s", tree_name);
env[1] = malloc_sprintf("GIT_DIR_ENVIRONMENT=%s", git_dir);
env[2] = malloc_sprintf("GIT_WORK_TREE+ENVIRONMENT=%s", path);
env[3] = NULL;
cp.env = env;
>>> + cp.argv = argv;
>>> + cp.git_cmd = 1;
>>> + cp.no_stdin = 1;
>>
>> I think you stll need "cp.dir = path;" here because the setup routines
>> won't do that for you. But I need to check/test that.
>>
> Originally I did set cp.dir but that is used by run_command (via
> start_command) to chdir. Which foils the cwd to worktree detection (at
> least in V1 of that patch).
Right. I forgot that. But then when new grep is run, it should move
back to worktree. I believe current grep code assumes that cwd is
worktree root.
--
Duy
next prev parent reply other threads:[~2010-10-18 3:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-15 23:26 [RGC/PATCHv2] grep: submodule support Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 1/5] worktree: provide better prefix to go back to original cwd Chris Packham
2010-10-16 18:42 ` Jonathan Nieder
2010-10-17 2:48 ` Chris Packham
2010-10-17 10:01 ` Nguyen Thai Ngoc Duy
2010-10-18 2:05 ` Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 2/5] grep: output the path from cwd to worktree Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 3/5] grep_cache: check pathspec first Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 4/5] add test for git grep --recursive Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 5/5] grep: add support for grepping in submodules Chris Packham
2010-10-17 10:28 ` Nguyen Thai Ngoc Duy
2010-10-18 2:01 ` Chris Packham
2010-10-18 3:37 ` Nguyen Thai Ngoc Duy [this message]
2010-10-16 15:54 ` [RGC/PATCHv2] grep: submodule support Jens Lehmann
2010-10-17 2:13 ` Chris Packham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTikUpUZrwj9S91ZarUbfkcPgpnyx3h54dJb2W9X0@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=judge.packham@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).