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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]