From: Junio C Hamano <gitster@pobox•com>
To: David Turner <dturner@twopensource•com>
Cc: git mailing list <git@vger•kernel.org>
Subject: Re: RFC: git cat-file --follow-symlinks?
Date: Wed, 29 Apr 2015 14:49:22 -0700 [thread overview]
Message-ID: <xmqqh9ry4nbx.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1430343059.14907.18.camel@ubuntu> (David Turner's message of "Wed, 29 Apr 2015 14:30:59 -0700")
David Turner <dturner@twopensource•com> 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.
next prev parent reply other threads:[~2015-04-29 21:49 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-29 20:57 RFC: git cat-file --follow-symlinks? David Turner
2015-04-29 21:16 ` Jonathan Nieder
2015-04-29 21:24 ` David Turner
2015-04-29 21:17 ` Junio C Hamano
2015-04-29 21:30 ` David Turner
2015-04-29 21:48 ` Jeff King
2015-04-29 22:19 ` Jonathan Nieder
2015-04-29 23:05 ` Jeff King
2015-04-29 22:29 ` David Turner
2015-04-29 23:11 ` Jeff King
2015-04-30 0:37 ` Jeff King
2015-04-30 1:06 ` David Turner
2015-04-30 1:16 ` Jeff King
2015-04-30 1:31 ` Junio C Hamano
2015-04-30 3:18 ` Jeff King
2015-04-30 1:45 ` David Turner
2015-04-30 3:37 ` Jeff King
2015-04-30 5:34 ` Junio C Hamano
2015-04-30 8:12 ` Michael Haggerty
2015-04-30 18:03 ` David Turner
2015-04-30 18:19 ` Junio C Hamano
2015-04-30 18:28 ` David Turner
2015-04-30 18:32 ` Jeff King
2015-04-30 18:44 ` David Turner
2015-04-30 18:49 ` Jeff King
2015-04-30 19:00 ` David Turner
2015-04-30 19:10 ` Jeff King
2015-04-30 19:17 ` David Turner
2015-04-30 10:04 ` Andreas Schwab
2015-04-30 18:27 ` Jeff King
2015-04-30 19:18 ` Junio C Hamano
2015-04-30 19:25 ` David Turner
2015-04-30 19:46 ` Junio C Hamano
2015-04-30 19:51 ` Jeff King
2015-04-30 20:05 ` Junio C Hamano
2015-05-01 3:29 ` David Turner
2015-05-01 5:36 ` Jeff King
2015-05-01 17:29 ` David Turner
2015-05-01 20:11 ` Jeff King
2015-05-01 21:09 ` David Turner
2015-04-29 21:49 ` Junio C Hamano [this message]
2015-04-29 22:47 ` David Turner
2015-04-30 8:10 ` Michael Haggerty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh9ry4nbx.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=dturner@twopensource$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox