From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Sergey Sergeev <gurugray@yandex.ru>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] archive: let remote clients get reachable commits
Date: Fri, 22 Feb 2013 13:26:54 -0500 [thread overview]
Message-ID: <20130222182654.GA18934@sigill.intra.peff.net> (raw)
In-Reply-To: <7vfw0odxz3.fsf@alter.siamese.dyndns.org>
On Fri, Feb 22, 2013 at 10:06:56AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > How are you proposing to verify master~12 in that example? Because
> > during parsing, it starts with "master", and we remember that?
>
> By not cheating (i.e. using get_sha1()), but making sure you can
> parse "master" and the adornment on it "~12" is something sane.
So, like these patches:
http://article.gmane.org/gmane.comp.version-control.git/188386
http://article.gmane.org/gmane.comp.version-control.git/188387
? They do not allow arbitrary sha1s that happen to point to branch tips,
but I am not sure whether that is something people care about or not.
> That is why I said "this is harder than one would naively think, but
> limiting will make it significantly easier". I didn't say that it
> would become "trivial", did I?
I'm not implying it would be trivial. It was an honest question, since
you did not seem to want to do the pass-more-information-out-of-get-sha1
approach last time this came up.
Even though those patches above are from me, I've come to the conclusion
that the best thing to do is to harmonize with upload-pack. Then you
never have the "well, but I could fetch it, so why won't upload-archive
let me get it" argument. Something like:
1. split name at first colon (like we already do)
2. make sure the left-hand side is reachable according to the same
rules that upload-pack uses. Right we just say "is it a ref". It
should be:
2a. if it is a commit-ish, is it reachable from a ref?
2b. otherwise, is it pointed to directly by a ref?
3. Abort if it's not reachable. Abort if it's not a tree-ish. No
checks necessary on the right-hand side, because a path lookup in a
tree-ish is always reachable from the tree-ish. I.e., the same rule
we have now.
I did not check if upload-pack will respect a "want" line for an object
accessible only by peeling a tag. But an obvious 2c could be "is it
accessible by peeling the refs?"
That leaves the only inaccessible thing as direct-sha1s of trees and
blobs that are reachable from commits. But you also cannot ask for those
directly via upload-pack, and I do not think it's worth it to do the
much more expensive reachability check to verify those (OTOH, it is no
more expensive than the current "counting objects" for a clone, and we
could do it only as a fallback when cheaper checks do not work).
-Peff
next prev parent reply other threads:[~2013-02-22 18:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-21 14:24 [PATCH] archive: let remote clients get reachable commits Sergey Segeev
2013-02-21 15:52 ` Jeff King
[not found] ` <995301361532360@web22h.yandex.ru>
2013-02-22 17:10 ` Junio C Hamano
2013-02-22 17:27 ` Jeff King
2013-02-22 18:06 ` Junio C Hamano
2013-02-22 18:26 ` Jeff King [this message]
2013-02-22 19:15 ` Junio C Hamano
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=20130222182654.GA18934@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=gurugray@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).