git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Ian Harvey <iharvey@good.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] archive: loosen restrictions on remote object lookup
Date: Wed, 5 Jun 2013 12:38:23 -0400	[thread overview]
Message-ID: <20130605163823.GE8664@sigill.intra.peff.net> (raw)
In-Reply-To: <loom.20130529T133942-310@post.gmane.org>

On Wed, May 29, 2013 at 12:05:41PM +0000, Ian Harvey wrote:

> So, did this patch make it anywhere? We could really use it.
> 
> Here's the use case. The original ee27ca4 patch broke our build system when
> the git server was upgraded to Debian Wheezy last night. The builder fetches
> source from the repo in two pieces using git archive, and we need to make
> sure both pieces are from the same commit. So we get a sha1 hash with git
> ls-remote, and use it with git archive --remote. This, of course, breaks
> with the 'no such ref' error.

The patch you are responding to[1] would not help there, either. It does
not allow raw sha1s. The only way to do that would be:

  1. Add an option to the server to allow arbitrary sha1s, even if they
     are not reachable from the ref tips. This is an easy fix, but
     requires server admins to cooperate (and they may or may not want
     to lose the "you can only access reachable things policy".

  2. Actually do a reachability check. Doing a full object check to
     allow fetching an arbitrary tree by sha1 is probably prohibitively
     expensive[2], but we could allow the form "<commit>[:<path>]", check
     that "<commit>" is reachable, and then allow arbitrary paths within
     it.

> At the very least, the documentation is wrong when it talks about passing a
> commit ID to git archive: maintainers must surely agree that the
> documentation and the actual behavior ought to match.

I am not sure which documentation you mean. The part about "commit ID"
in the current manpage is drawing the distinction between something that
resolves to a commit versus something that resolves to a tree. Either is
available both locally and remotely. I think the use of the phrase
"commit ID" is questionable there, as it really means "something that
resolves to a commit", not "a sha1 commit ID". We used to use the phrase
"commit-ish" to refer to that, but I think it has fallen out of favor as
being too jargon-y.

The documentation does not mention at all the restrictions placed on
refs using "--remote", and it probably should.

-Peff

[1] http://article.gmane.org/gmane.comp.version-control.git/188387

[2] If we had a reachability bitmap cache, calculating arbitrary object
    reachability would actually be pretty cheap. But the bitmap feature
    for core git is not yet ready for prime-time, so I think we should
    not depend on it yet.

  reply	other threads:[~2013-06-05 16:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10 21:18 [BUG] git archive broken in 1.7.8.1 Albert Astals Cid
2012-01-10 21:33 ` Carlos Martín Nieto
2012-01-10 22:05   ` Albert Astals Cid
2012-01-10 22:50     ` Carlos Martín Nieto
2012-01-10 23:21       ` Jeff King
2012-01-11 12:12         ` [PATCH] archive: re-allow HEAD:Documentation on a remote invocation Carlos Martín Nieto
2012-01-11 19:39           ` Jeff King
2012-01-11 19:42             ` [PATCH 1/2] get_sha1_with_context: report features used in resolution Jeff King
2012-01-12  2:36               ` Junio C Hamano
2012-01-12  2:51                 ` Jeff King
2012-01-11 19:42             ` [PATCH 2/2] archive: loosen restrictions on remote object lookup Jeff King
2013-05-29 12:05               ` Ian Harvey
2013-06-05 16:38                 ` Jeff King [this message]
2013-06-05 22:35                   ` [RFC/PATCH 0/4] real reachability checks for upload-archive Jeff King
2013-06-05 22:37                     ` [PATCH 1/4] clear parsed flag when we free tree buffers Jeff King
2013-06-06 17:55                       ` Junio C Hamano
2013-06-05 22:39                     ` [PATCH 2/4] upload-archive: restrict remote objects with reachability check Jeff King
2013-06-05 22:40                     ` [PATCH 3/4] list-objects: optimize "revs->blob_objects = 0" case Jeff King
2013-06-05 22:40                     ` [PATCH 4/4] archive: ignore blob objects when checking reachability Jeff King
2013-06-06  7:57                       ` Michael Haggerty
2013-06-07  0:50                       ` Eric Sunshine
2013-06-06 17:27                     ` [RFC/PATCH 0/4] real reachability checks for upload-archive Junio C Hamano
2012-01-12  2:46           ` [PATCH] archive: re-allow HEAD:Documentation on a remote invocation Junio C Hamano
2012-01-12  2:54             ` Jeff King
2012-01-12  2:59               ` Jeff King
2012-01-12  3:03               ` Junio C Hamano
2012-01-12  3:10                 ` Jeff King
2012-01-12  3:20                   ` Junio C Hamano
2012-01-10 23:01     ` [BUG] git archive broken in 1.7.8.1 Allan Wind
2012-01-11 12:51       ` Carlos Martín Nieto

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130605163823.GE8664@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=iharvey@good.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).