Re: RFC: git cat-file --follow-symlinks?

From: Jeff King <peff@peff.net>
Date: Apr 29, 2015, 23:11 UTC
Message-ID: <20150429231150.GB3887@peff.net>
In-Reply-To: <1430346576.14907.40.camel@ubuntu>

On Wed, Apr 29, 2015 at 03:29:36PM -0700, David Turner wrote:

Show 13 quoted lines

> Overall, I agree.  I think the disadvantages are somewhat overstated.
> 
> As I said above, I don't think the cwd is a problem.  The output for
> symlinks which point outside the repo should be absolute (in the case of
> absolute symlinks), or relative to the repo root (for relative
> symlinks).  In other words, if my repo contains:
> foo/bar -> ../../baz
> then the output[1] would be 
> symlink 6
> ../baz
> 
> I can't think of any other output that would be reasonable here, but
> maybe there's something I don't understand.

Yeah, I agree if you let git punt on leaving the filesystem, most of the complicated problems go away. It still feels a bit more magical than I expect out of cat-file, and there are still corner cases (e.g., do we do cycle detection? Or just have a limit to the recursion depth?)

And if you are punting on some cases, I think you'd still want to be able to report on the symlinks you couldn't resolve (e.g., because they went out of tree, pointed to non-existent files, or caused cycles). So it seems like %(intreemode) is a good first step, because it lets you express that (and more).

And then you could implement --follow-symlinks on top of that; it can't catch all cases, but you've left callers with an escape hatch to do their own resolution if they want, without having to implement a new syntax for it.

-Peff