On Wed, 2015-04-29 at 14:17 -0700, Junio C Hamano wrote: > David Turner <dturner@xxxxxxxxxxxxxxxx> 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. -- 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