Duy Nguyen pclo...@gmail.com writes:
On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
Hmm.. Junio already did most of the work in 051e400 (helping
smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to
do is enable
On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
Hmm.. Junio already did most of the work in 051e400 (helping
smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to
do is enable uploadpack.allowtipsha1inwant and apply this
On Tue, Oct 7, 2014 at 1:25 AM, Patrick Donnelly batr...@batbytes.com wrote:
On Thu, Oct 2, 2014 at 12:10 PM, Jeff King p...@peff.net wrote:
On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote:
My understanding is that you are allowed to ask for a SHA1, but most
git servers refuse the
On Tue, Oct 07, 2014 at 07:34:36PM +0700, Duy Nguyen wrote:
If we can verify the asked sha-1 is reachable from the visible ref
set, then we should allow it. With pack bitmaps, it's getting much
cheaper to do such a test. If pack bitmaps are not used, we could
set a default/configurable limit,
Duy Nguyen pclo...@gmail.com writes:
Hmm.. Junio already did most of the work in 051e400 (helping
smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to
do is enable uploadpack.allowtipsha1inwant and apply this patch
Not that patch, I would think.
I would understand if
On Thu, Oct 2, 2014 at 12:10 PM, Jeff King p...@peff.net wrote:
On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote:
My understanding is that you are allowed to ask for a SHA1, but most
git servers refuse the request. But if you already have the SHA
locally, then git doesn't neet to
On Mon, 6 Oct 2014, Patrick Donnelly wrote:
There are efforts in the scientific communities at preserving
experimental software and results. One of the things we'd like to do
is shallow clone a specific sha1 commit from e.g. GitHub. [I think
GitHub has this disabled though? I haven't been able
I also like the feature of being able to fetch commits by SHA-1. My
problem is that it is not clear to end users whether they can fetch
SHA-1 from a specific server or not. For exactly the same server a
git fetch origin id-of-commit-x first doesn't work and all of the
sudden that command works and
I always though during fetch I have to specify a refspec and that a
sha1 would not be accepted as a ref. Firing some like 'git fetch
origin sha1' should be forbidden. But in fact I see that such a
fetch command succeeds if you already have that object in your local
repo.
My question: is it
On Thu, Oct 2, 2014 at 9:57 AM, Christian Halstrick
christian.halstr...@gmail.com wrote:
I always though during fetch I have to specify a refspec and that a
sha1 would not be accepted as a ref. Firing some like 'git fetch
origin sha1' should be forbidden. But in fact I see that such a
fetch
On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote:
git show af00f4c39bcc8dc29ed8f59a47066d5993c279e4
fatal: bad object af00f4c39bcc8dc29ed8f59a47066d5993c279e4
git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4
error: no such remote ref
Jeff King wrote:
But I think Christian is arguing that the client side should complain
that $sha1 is not a remote ref, and therefore not something we can
fetch. This used to be the behavior until 6e7b66e (fetch: fetch objects
by their exact SHA-1 object names, 2013-01-29). The idea there is
12 matches
Mail list logo
