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

[David Turner <dturner@twopensource.com>]

On Wed, 2015-04-29 at 14:17 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
> 
> > Do people think this is reasonable?
> 
> I personally don't, exactly because we track the contents of the
> symlink itself, not the referent.  Your "major wrinkle" that they
> can point outside the repository is a mere manifestation of that.

I'm not sure I understand why tracking the contents of the symlink is a
problem for this approach.  It seems reasonable to ask what would have
happened had I checked out the repo at a certain SHA and said "cat
foo/bar/baz".

> The format specifiers the --batch option takes do not exactly give
> you what the in-tree type of the thing is, to allow the receiving
> end that parses the tagline (which it needs to do anyway in order to
> find out where the current record ends) act on it.  %(objecttype)
> would just say "blob" and you cannot tell if it is a plain file,
> executable or a symbolic link.
> 
> Perhaps an ideal interface might be something like this:
> 
>     $ echo HEAD:RelNotes |
>       git cat-file --batch='%(objecttype) %(intreemode) %(objectsize)'
>     blob 160000 32
>     Documentation/RelNotes/2.4.0.txt
> 
> I suspect it would be just the matter of teaching "cat-file --batch"
> to read from get_sha1_with_context() in batch_one_object(), instead
> of reading from get_sha1() which it currently does.
> 
> And that inteferface I think I can live with.

Even if I had %(intreemode), I would still have to do a recursive search
to figure out whether Documentation or RelNotes was a symlink.  This is
why I want a follow-symlinks mode.  And since I am already reading
RelNotes, I can (and presently do) parse the mode out of that data.
$(intreedmode) would save me some parsing, but it would not save me any
reading, nor would it make my code any less complex.  But
--follow-symlinks would simplify my code.