Jeff King writes:
> It somehow feels a little weird to me that we would output the
> information about refs/foo on the HEAD line.
I see that you realized why the above is not the case in the
downthread; the capability list is not about describing HEAD. The
list happens to be on the line for HEAD
On Sun, Sep 08, 2013 at 03:13:59AM -0400, Jeff King wrote:
> What do you think about teaching git to read extra data after "\0" for
> _every_ ref line? And then ref advertisement might look something like:
>
>HEAD\0multi_ack thin-pack ... symref=refs/heads/master\n
>refs/heads/master\n
>
On Fri, Sep 06, 2013 at 10:46:24AM -0700, Junio C Hamano wrote:
> I think it is perfectly fine to expose _only_ HEAD now, and wait
> until we find a good reason that we should send this information for
> other symbolic refs in the repository.
Yeah, I agree with that.
> However, because we alread
Andreas Krey writes:
> On Fri, 06 Sep 2013 10:46:24 +, Junio C Hamano wrote:
>> Andreas Krey writes:
>>
> ...
>> reason later, on-the-wire format should be prepared to support such
>> later enhancement. I think sending
>>
>> symref=HEAD:refs/heads/master
>
> Mirco-bikeshed: Should th
On Fri, 06 Sep 2013 10:46:24 +, Junio C Hamano wrote:
> Andreas Krey writes:
>
...
> reason later, on-the-wire format should be prepared to support such
> later enhancement. I think sending
>
> symref=HEAD:refs/heads/master
Mirco-bikeshed: Should that possibly be
symref:HEAD=refs/
Andreas Krey writes:
> From: Junio C Hamano
>
> This implements the server side of protocol extension to show which branch
> the HEAD points at. The information is sent as a capability symref=.
>
> Signed-off-by: Junio C Hamano
> Signed-off-by: Andreas Krey
> ---
> upload-pack.c | 8 ++--
6 matches
Mail list logo
