From: Dennis Kaarsemaker <dennis@kaarsemaker.net>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Thomas Rast <tr@thomasrast.ch>,
Git Mailing List <git@vger.kernel.org>,
ingy@ingy.net
Subject: Re: [PATCH] path_treatment: also ignore $GIT_DIR if it's not .git
Date: Mon, 02 Dec 2013 12:40:12 +0100 [thread overview]
Message-ID: <1385984412.3240.17.camel@localhost> (raw)
In-Reply-To: <CACsJy8AuSej7Pwm5Tbo5r_FNaND1-E62Btk=7dZ74YD8K6UJDg@mail.gmail.com>
On ma, 2013-12-02 at 16:35 +0700, Duy Nguyen wrote:
> On Mon, Dec 2, 2013 at 3:01 PM, Dennis Kaarsemaker
> <dennis@kaarsemaker.net> wrote:
> > On ma, 2013-12-02 at 07:38 +0700, Duy Nguyen wrote:
> >> On Mon, Dec 2, 2013 at 6:38 AM, Dennis Kaarsemaker
> >> <dennis@kaarsemaker.net> wrote:
> >> > On ma, 2013-12-02 at 00:08 +0100, Thomas Rast wrote:
> >> >> Duy Nguyen <pclouds@gmail.com> writes:
> >> >>
> >> >> > On Mon, Dec 2, 2013 at 2:04 AM, Dennis Kaarsemaker
> >> >> > <dennis@kaarsemaker.net> wrote:
> >> >> >> We always ignore anything named .git, but we should also ignore the git
> >> >> >> directory if the user overrides it by setting $GIT_DIR
> >> >> [...]
> >> >> >> + if (simplify_away(path->buf, path->len, simplify) || is_git_directory(path->buf))
> >> >> >> return path_none;
> >> >> >
> >> >> > this adds 2 access, 1 lstat, 1 open, 1 read, 1 close to _every_ path
> >> >> > we check. Is it worth the cost?
> >> >>
> >> >> Moreover it is a much more inclusive check than what the commit message
> >> >> claims: it will ignore anything that looks like a .git directory,
> >> >> regardless of the name. In particular GIT_DIR doesn't have anything to
> >> >> do with it.
> >> >
> >> > Ah, yes thanks, that's rather incorrect indeed. How about the following
> >> > instead? Passes all tests, including the new one.
> >> >
> >> > --- a/dir.c
> >> > +++ b/dir.c
> >> > @@ -1198,7 +1198,7 @@ static enum path_treatment treat_path(struct dir_struct *dir,
> >> > return path_none;
> >> > strbuf_setlen(path, baselen);
> >> > strbuf_addstr(path, de->d_name);
> >> > - if (simplify_away(path->buf, path->len, simplify))
> >> > + if (simplify_away(path->buf, path->len, simplify) || !strncmp(get_git_dir(), path->buf, path->len))
> >> > return path_none;
> >>
> >> get_git_dir() may return a relative or absolute path, depending on
> >> GIT_DIR/GIT_WORK_TREE. path->buf is always relative. You'll pass one
> >> case with this (relative vs relative) and fail another. It might be
> >> simpler to just add get_git_dir(), after converting to relative path
> >> and check if it's in worktree, to the exclude list and let the current
> >> exclude mechanism handle it.
> >
> > This type of invocation really only works from the root of the workdir
> > anyway and both a relative and absolute path work just fine:
> >
> > dennis@lightning:~/code/git$ GIT_DIR=$(pwd)/.foo ./git status
> > On branch master
> > nothing to commit, working directory clean
> > dennis@lightning:~/code/git$ GIT_DIR=./.foo ./git status
> > On branch master
> > nothing to commit, working directory clean
> >
> > Well, unless you set GIT_WORK_TREE as well, but then it still works:
> >
> > dennis@lightning:~/code/git/t$ GIT_DIR=$(pwd)/../.foo GIT_WORK_TREE=.. ../git status
> > On branch master
> > nothing to commit, working directory clean
> > dennis@lightning:~/code/git/t$ GIT_DIR=../.foo GIT_WORK_TREE=.. ../git status
> > On branch master
> > nothing to commit, working directory clean
> >
> > So I'm wondering when you think this will fail. Because then I can add a
> > test for that case too.
>
> ~/w/git $ cd t
> ~/w/git/t $ GIT_TRACE_SETUP=1 ../git --git-dir=../.git --work-tree=..
> --no-pager status
> setup: git_dir: /home/pclouds/w/git/.git
> setup: worktree: /home/pclouds/w/git
> setup: cwd: /home/pclouds/w/git
> setup: prefix: t/
> On branch exclude-pathspec
> Your branch and 'origin/master' have diverged,
> and have 2 and 5 different commits each, respectively.
>
> I can't say this is the only case though. One has to audit to all
> possible setup cases in setup_git_directory() to make that claim.
I'm probably missing something, but that's the same as my second
example, and works. I also tried running it from completely outside the
repo:
dennis@lightning:~$ code/git/git --git-dir=code/git/.foo --work-tree=code/git status
On branch master
nothing to commit, working directory clean
dennis@lightning:~$ code/git/git --git-dir=/home/dennis/code/git/.foo --work-tree=code/git status
On branch master
nothing to commit, working directory clean
--
Dennis Kaarsemaker
www.kaarsemaker.net
next prev parent reply other threads:[~2013-12-02 11:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-01 7:06 GIT_DIR not auto ignored Ingy dot Net
2013-12-01 18:08 ` Dennis Kaarsemaker
2013-12-01 18:30 ` Dennis Kaarsemaker
2013-12-01 19:04 ` [PATCH] path_treatment: also ignore $GIT_DIR if it's not .git Dennis Kaarsemaker
2013-12-01 23:02 ` Duy Nguyen
2013-12-01 23:08 ` Thomas Rast
2013-12-01 23:38 ` Dennis Kaarsemaker
2013-12-02 0:38 ` Duy Nguyen
2013-12-02 8:01 ` Dennis Kaarsemaker
2013-12-02 9:35 ` Duy Nguyen
2013-12-02 11:40 ` Dennis Kaarsemaker [this message]
2013-12-02 12:01 ` Duy Nguyen
2013-12-02 1:21 ` Eric Sunshine
2013-12-03 15:18 ` Karsten Blees
2013-12-03 18:32 ` Junio C Hamano
2013-12-03 19:00 ` Karsten Blees
2013-12-03 19:07 ` Jonathan Nieder
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=1385984412.3240.17.camel@localhost \
--to=dennis@kaarsemaker.net \
--cc=git@vger.kernel.org \
--cc=ingy@ingy.net \
--cc=pclouds@gmail.com \
--cc=tr@thomasrast.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.