David Turner <dturner@xxxxxxxxxxxxxxxx> writes:
>> 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.
Yes, and why is that a problem? Think of "cat-file --batch" an
"object server" you query interactively. You start the process, ask
it about HEAD:RelNotes, and learn that the blob is a link that
points at Documentation/RelNotes/2.4.0.txt. Then you ask it about
"HEAD:Documentation/RelNotes/2.4.0.txt", which _may_ answer "no such
file", at which point you can start worrying about referring to
places outside the tree (i.e. untracked).
"cat-file" does not know about your project, and especially its
external dependencies, if a symbolic link ever steps outside the
tree objects, better than you do. Because it is a low-level
plumbing command, allowing it to make policy decisions (e.g. "if
outside repository, always look at the filesystem that the program
happens to be running" [*1*]) is something I would reject as much as
possible. It will paint us into a corner we cannot later escape out
of.
> 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.
mode? How? If all you have is an blob object name and no context
around it (i.e. the top-level tree object has that blob with 160000
mode bits), you cannot tell a symlink from a regular file.
[Footnote]
*1* For example, you may have two projects's working trees A and B
sitting next to each other, and A/sibling may be a symbolic link
that points at ../B/some/thing. A Porcelain that uses cat-file
--batch as "the object server" may notice v1.0:sibling in A's
history points at ../B/some/thing and would want to grab
some/thing from the contemporary version of B's commit, instead
of just blindly going to the filesystem.
--
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