Jonathan Nieder writes:
> Given that there aren't any servers that are going to produce this
> kind of bad input anyway, I prefer a die().
That would certainly put bigger pressure on the folks who write
buggy stuff in the future. If we know that nobody produces such
output, I'd prefer to forbid
Junio C Hamano wrote:
> Jonathan Tan writes:
>> diff --git a/connect.c b/connect.c
>> index 722dc3f..0c2221e 100644
>> --- a/connect.c
>> +++ b/connect.c
>> @@ -165,6 +165,9 @@ struct ref **get_remote_heads(int in, char *src_buf,
>> size_t src_len,
>> continue;
>>
Jonathan Tan writes:
> diff --git a/connect.c b/connect.c
> index 722dc3f..0c2221e 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -165,6 +165,9 @@ struct ref **get_remote_heads(int in, char *src_buf,
> size_t src_len,
> continue;
> }
>
> + if (!
Jonathan Tan writes:
> Git advertises the same capabilities^{} ref in its ref advertisement for push
> but since it never remembered to do so for fetch, the client forgot to handle
> this case. Handle it.
> ...
> In this aspect, JGit is compliant with the specification in pack-protocol.txt.
I ag
On Fri, Sep 02, 2016 at 04:51:45PM -0700, Jonathan Nieder wrote:
> > I'd be more interested in the pain of this transition if there was a
> > concrete use case for "hide literally all refs, but still allow
> > fetches". Is that a thing that people do?
>
> Sure, it is a thing that people do. For
Stefan Beller wrote:
> On Fri, Sep 2, 2016 at 4:35 PM, Jeff King wrote:
>> I'd be more interested in the pain of this transition if there was a
>> concrete use case for "hide literally all refs, but still allow
>> fetches". Is that a thing that people do?
[...]
> Not to derail the discussion to m
Jeff King wrote:
> On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote:
> But combining hideRefs with
> allowTipSHA1InWant could trigger this case.
Yes.
[...]
> I'd be more interested in the pain of this transition if there was a
> concrete use case for
On Fri, Sep 2, 2016 at 4:35 PM, Jeff King wrote:
> I'd be more interested in the pain of this transition if there was a
> concrete use case for "hide literally all refs, but still allow
> fetches". Is that a thing that people do?
>
Not yet, I would think.
Not to derail the discussion to much, bu
On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote:
> The cause is that, since v3.1.0.201309270735-rc1~22 (Advertise capabilities
> with no refs in upload service., 2013-08-08), JGit's ref advertisement
> includes
> a ref named capabilities^{} to advertise its capabilities on, while git
Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> connect.c| 3 +++
> t/t5512-ls-remote.sh | 39 +++
> 2 files changed, 42 insertions(+)
Reviewed-by: Jonathan Nieder
Thanks.
When cloning an empty repository served by standard git, "git clone" produces
the following reassuring message:
$ git clone git://localhost/tmp/empty
Cloning into 'empty'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
Mean
11 matches
Mail list logo
