From: Chris Packham <judge.packham@gmail.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: "Jens.Lehmann" <Jens.Lehmann@web.de>, git <git@vger.kernel.org>
Subject: Re: [RFC PATCH 2/3] grep: prepare grep for submodules
Date: Fri, 01 Oct 2010 09:26:29 -0700 [thread overview]
Message-ID: <4CA60BB5.4080202@gmail.com> (raw)
In-Reply-To: <AANLkTikH+sd2kPAraGSTB-ik-Toz3s2nTLoLVOj86oSm@mail.gmail.com>
On 01/10/10 07:37, Nguyen Thai Ngoc Duy wrote:
> On 10/1/10, Chris Packham <judge.packham@gmail.com> wrote:
>> > You can make setup_explicit_git_dir() realize that situation (current
>> > working directory outside $GIT_WORK_TREE), then calculate and save the
>> > submodule prefix in startup_info struct. Then "git grep" or any
>> > commands can just read startup_info to find out the submodule prefix.
>>
>>
>> Here's my first naive attempt at implementing what you describe. Needs
>> tests, more comments, sign-off etc.
>
> Thanks.
>
>> One situation that could be handled better is when the cwd is a
>> subdirectory of the specified worktree. At the moment this ends up
>> giving the full path to the worktree, the output would look much nicer
>> if it gave the relative path (e.g. ../../).
>
> Hmm.. if cwd is inside a worktree, prefix (the 3rd parameter in
> cmd_grep) should be correctly set and "git grep" should also show
> relative path. Or are you talking about another command?
I was testing this with grep but also with my submodule changes. I
should probably move this to its own topic branch and get it working
then rebase my grep changes on top of it.
>>
>> ---8<---
>> From: Chris Packham <judge.packham@gmail.com>
>> Date: Thu, 30 Sep 2010 11:19:29 -0700
>> Subject: [RFC PATCH] save the work tree prefix in startup_info
>>
>> This is the relative path between the cwd and the worktree or the
>> absolute path of the worktree if the worktree is not a subdirectory
>> of the worktree.
>> ---
>> cache.h | 1 +
>> dir.c | 26 ++++++++++++++++++++++++++
>> dir.h | 1 +
>> setup.c | 4 ++++
>> 4 files changed, 32 insertions(+), 0 deletions(-)
>>
>> diff --git a/cache.h b/cache.h
>> index e1d3ffd..f320e78 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -1111,6 +1111,7 @@ const char *split_cmdline_strerror(int cmdline_errno);
>> /* git.c */
>> struct startup_info {
>> int have_repository;
>> + const char *prefix;
>
> You should use another name here to avoid confusion with the current
> prefix, relative to worktree toplevel directory. I'm thinking of
> outer_prefix or cwd_prefix, but I'm usually bad at naming.
I couldn't come up with a better name either, that’s why I used
"prefix". "cwd_prefix" seems sensible enough to me.
>> };
>> extern struct startup_info *startup_info;
>>
>> diff --git a/dir.c b/dir.c
>> index 58ec1a1..2148730 100644
>> --- a/dir.c
>> +++ b/dir.c
>> @@ -1036,6 +1036,32 @@ char *get_relative_cwd(char *buffer, int size,
>> const char *dir)
>> }
>> }
>>
>> +char *get_relative_wt(char *buffer, int size, const char *dir)
>> +{
>> + char *cwd = buffer;
>> +
>> + if (!dir)
>> + return NULL;
>> + if (!getcwd(buffer, size))
>> + die_errno("can't find the current directory");
>> + if (!is_absolute_path(dir))
>> + dir = make_absolute_path(dir);
>> + if (strstr(dir, cwd)) {
>
> Why not strncmp?
I actually tried strcmp first, expecting to get a number that I can
increment dir by. What I actually got was -1, maybe I just screwed up
the order of dir and cwd. I'll look into it.
>
>> + dir += strlen(cwd);
>> + switch(*dir){
>> + case '\0':
>> + return NULL;
>> + case '/':
>> + dir++;
>> + break;
>
> Yeah.
>
>> + default:
>> + break;
>
> Should we properly handle relative path that includes ".." here too?
By now dir and cwd are both absolute paths. So I dn't think there is
anything to handle
>> + }
>> + }
>> + strncpy(buffer, dir, size);
>
> So if "cwd" is inside "dir", an absolute "dir" is returned? That does
> not look like a prefix to me.
That is a problem. Maybe I should be returning NULL in that case and let
the existing code handle the cwd inside dir case. I think if I wrote
some tests first I could see the various permutations better.
>> + return buffer;
>> +}
>> +
>> int is_inside_dir(const char *dir)
>> {
>> char buffer[PATH_MAX];
>> diff --git a/dir.h b/dir.h
>> index b3e2104..d3c161f 100644
>> --- a/dir.h
>> +++ b/dir.h
>> @@ -81,6 +81,7 @@ extern void add_exclude(const char *string, const char
>> *base,
>> extern int file_exists(const char *);
>>
>> extern char *get_relative_cwd(char *buffer, int size, const char *dir);
>> +extern char *get_relative_wt(char *buffer, int size, const char *dir);
>> extern int is_inside_dir(const char *dir);
>>
>> static inline int is_dot_or_dotdot(const char *name)
>> diff --git a/setup.c b/setup.c
>> index a3b76de..bd9d9fd 100644
>> --- a/setup.c
>> +++ b/setup.c
>> @@ -317,6 +317,7 @@ static const char *setup_explicit_git_dir(const char
>> *gitdirenv,
>> const char *work_tree_env, int *nongit_ok)
>> {
>> static char buffer[1024 + 1];
>> + static char wtbuf[1024 + 1];
>> const char *retval;
>>
>> if (PATH_MAX - 40 < strlen(gitdirenv))
>> @@ -337,6 +338,9 @@ static const char *setup_explicit_git_dir(const char
>> *gitdirenv,
>> }
>> if (check_repository_format_gently(nongit_ok))
>> return NULL;
>> +
>> + startup_info->prefix=get_relative_wt(wtbuf, sizeof(wtbuf) - 1,
>> + get_git_work_tree());
>> retval = get_relative_cwd(buffer, sizeof(buffer) - 1,
>> get_git_work_tree());
>> if (!retval || !*retval)
>>
>> --
>> 1.7.3.1
>>
>>
>
>
next prev parent reply other threads:[~2010-10-01 16:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 20:28 [RFC PATCH 0/3] grep: submodule support Chris Packham
2010-09-29 20:28 ` [RFC PATCH 1/3] add test for git grep --recursive Chris Packham
2010-09-29 20:35 ` Ævar Arnfjörð Bjarmason
2010-09-29 20:48 ` Chris Packham
2010-09-29 21:34 ` Kevin Ballard
2010-09-29 20:28 ` [RFC PATCH 2/3] grep: prepare grep for submodules Chris Packham
2010-09-30 1:10 ` Nguyen Thai Ngoc Duy
2010-09-30 18:34 ` Chris Packham
2010-10-01 14:37 ` Nguyen Thai Ngoc Duy
2010-10-01 16:26 ` Chris Packham [this message]
2010-09-29 20:28 ` [RFC PATCH 3/3] grep: add support for grepping in submodules Chris Packham
2010-09-29 22:21 ` Jens Lehmann
2010-09-29 22:59 ` Junio C Hamano
2010-09-29 23:47 ` Chris Packham
2010-09-30 11:09 ` Jens Lehmann
2010-09-30 11:28 ` Johannes Sixt
2010-09-30 15:07 ` Jens Lehmann
2010-09-29 23:02 ` Chris Packham
2010-09-30 11:24 ` Jens Lehmann
2010-09-30 16:48 ` Chris Packham
2010-09-30 18:59 ` Heiko Voigt
2010-09-30 19:48 ` Jens Lehmann
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=4CA60BB5.4080202@gmail.com \
--to=judge.packham@gmail.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=pclouds@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).