From: Jakub Narebski <jnareb@gmail.com>
To: Jeff King <peff@peff.net>
Cc: "Rob (gmail)" <robvanb@gmail.com>, git@vger.kernel.org
Subject: Re: New to Git / Questions about single user / multiple projects
Date: Wed, 19 Aug 2009 15:20:54 +0200 [thread overview]
Message-ID: <200908191520.56436.jnareb@gmail.com> (raw)
In-Reply-To: <20090819124820.GC20381@coredump.intra.peff.net>
On Wed, 19 August 2009, Jeff King <peff@peff.net> wrote:
> On Wed, Aug 19, 2009 at 02:18:07PM +0200, Jakub Narebski wrote:
>
> > More complicated solution, used by gitweb, requires Perl, not checked
> > that it works correctly, doesn't work with ancient repositories with
> > symlink HEAD.
> >
> > $ perl -e '
> > use File::Find qw(find);
> > my @list = ();
> > find({follow_fast => 1, follow_skip => 2, dangling_symlinks => 0,
> > wanted => sub {
> > return if (m!^[/.]$!);
> > return unless (-d $_);
> > push @list, $_ if -e "$_/HEAD"
> > }});
> > print join("\n", @list)."\n";
> > '
>
> That doesn't seem very accurate. It will find 'HEAD' in "logs/" of
> repositories with reflogs enabled, and "refs/remotes/*/" of cloned
> repositories, giving you a lot of false positives.
To be more exact it is simplified solution used by git; in this case
_oversimplified_, as gitweb doesn't have problems with 'HEAD' in
remote-tracking branches.
On the other hand gitweb currently does not detect submodules or
submodule-like repositories, i.e. repositories inside working directory
of other repository. So this could be improved...
>
> If you want accuracy, you can ask git rev-parse to verify whether a
> directory is a git repo; it actually uses a few different heuristics to
> check. For example:
>
> find . -type d |
> while read dir; do
> if GIT_DIR=$dir git rev-parse --git-dir >/dev/null 2>&1; then
Or "git --git-dir=$dir rev-parse 2> /dev/null"
> echo $dir
> fi
> done
>
> but it is a bit slower, as you invoke rev-parse for every directory, and
> it actually does some verification of the contents of HEAD (so it is
> probably a bad idea for something like gitweb, which cares about
> performance).
>
> If you want to do a cheap and fast check, searching for 'HEAD', 'refs',
> and 'objects' in the same directory is a reasonable heuristic.
If one follow preferred git conventions for naming non-bare repositories,
and one doesn't have anything funny,
$ find . -name "*.git" -type d
should be sufficient.
--
Jakub Narebski
Poland
prev parent reply other threads:[~2009-08-19 13:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 1:52 New to Git / Questions about single user / multiple projects Rob (gmail)
2009-08-19 2:24 ` Changsheng Jiang
2009-08-19 4:14 ` Chris Packham
2009-08-19 4:00 ` Daniel Barkalow
2009-08-19 7:59 ` Jakub Narebski
2009-08-19 11:00 ` Rob (gmail)
2009-08-19 12:18 ` Jakub Narebski
2009-08-19 12:28 ` Rob (gmail)
2009-08-19 12:49 ` Jeff King
2009-08-19 12:48 ` Jeff King
2009-08-19 13:20 ` Jakub Narebski [this message]
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=200908191520.56436.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=robvanb@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).