git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: David Turner <dturner@twopensource.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	git mailing list <git@vger.kernel.org>
Subject: Re: RFC: git cat-file --follow-symlinks?
Date: Thu, 30 Apr 2015 15:10:43 -0400	[thread overview]
Message-ID: <20150430191043.GA4461@peff.net> (raw)
In-Reply-To: <1430420422.22711.37.camel@ubuntu>

On Thu, Apr 30, 2015 at 12:00:22PM -0700, David Turner wrote:

> > > Also, BUILD files are scattered throughout the tree, so the entire tree
> > > would still need to be traversed.  At present, our monorepo is not quite
> > > large enough for this to matter (a full ls-tree only takes me 0.6s), but
> > > it is growing.
> > 
> > But aren't you asking git to do that internally? I.e., it can limit the
> > traversal for a prefix-match, but it cannot do so for an arbitrary
> > filename. It has to open every tree. So the extra expense is really just
> > the I/O over the pipe. That's not optimal, but it is a constant factor
> > slowdown from what git would do internally.
> 
> No, I'm not trying to find all BUILD files -- only ones that are in the
> transitive dependency tree of the target I'm trying to sparsely check
> out. So if the target foo/bar/baz depends on morx/fleem, and morx/fleem
> depends on plugh/xyzzy, then I have to examine those three places only.
> I don't have to examine anything in the gibbberish/ subtree, for
> instance.  

OK, let me see if I understand your use case by parroting it back.

You _don't_ want to feed git a "find all BUILD" pattern, which is good
(because it doesn't work ;) ). You do want to feed it a set of raw
paths to find, because you're going to discover the paths yourself at
each step as you recurse through the dependency-chain of build files. 
You don't actually care about feeding those paths to "ls-tree" at all.
You care only about the _content_ at each path (and will parse that
content to see if you need to take a further recursive step).

So I think git out-of-the-box supports that pretty well (via cat-file).
And your sticking point is that some of the paths may involve symlinks
in the tree, so you want cat-file to answer "if I had checked this out
and typed cat /some/path/to/BUILD, what content would I get". Which
brings us back to the original symlink question.

Is that all accurate?

I'm not sure that helps with the "how to handle symlinks" discussion,
but at least your goals make sense to me at this point.

-Peff

  reply	other threads:[~2015-04-30 19:10 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-29 20:57 RFC: git cat-file --follow-symlinks? David Turner
2015-04-29 21:16 ` Jonathan Nieder
2015-04-29 21:24   ` David Turner
2015-04-29 21:17 ` Junio C Hamano
2015-04-29 21:30   ` David Turner
2015-04-29 21:48     ` Jeff King
2015-04-29 22:19       ` Jonathan Nieder
2015-04-29 23:05         ` Jeff King
2015-04-29 22:29       ` David Turner
2015-04-29 23:11         ` Jeff King
2015-04-30  0:37           ` Jeff King
2015-04-30  1:06             ` David Turner
2015-04-30  1:16               ` Jeff King
2015-04-30  1:31                 ` Junio C Hamano
2015-04-30  3:18                   ` Jeff King
2015-04-30  1:45                 ` David Turner
2015-04-30  3:37                   ` Jeff King
2015-04-30  5:34                     ` Junio C Hamano
2015-04-30  8:12                       ` Michael Haggerty
2015-04-30 18:03                         ` David Turner
2015-04-30 18:19                           ` Junio C Hamano
2015-04-30 18:28                             ` David Turner
2015-04-30 18:32                               ` Jeff King
2015-04-30 18:44                                 ` David Turner
2015-04-30 18:49                                   ` Jeff King
2015-04-30 19:00                                     ` David Turner
2015-04-30 19:10                                       ` Jeff King [this message]
2015-04-30 19:17                                         ` David Turner
2015-04-30 10:04                     ` Andreas Schwab
2015-04-30 18:27                       ` Jeff King
2015-04-30 19:18                         ` Junio C Hamano
2015-04-30 19:25                     ` David Turner
2015-04-30 19:46                       ` Junio C Hamano
2015-04-30 19:51                         ` Jeff King
2015-04-30 20:05                         ` Junio C Hamano
2015-05-01  3:29                     ` David Turner
2015-05-01  5:36                       ` Jeff King
2015-05-01 17:29                         ` David Turner
2015-05-01 20:11                           ` Jeff King
2015-05-01 21:09                             ` David Turner
2015-04-29 21:49     ` Junio C Hamano
2015-04-29 22:47       ` David Turner
2015-04-30  8:10 ` Michael Haggerty

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=20150430191043.GA4461@peff.net \
    --to=peff@peff.net \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    /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).