On Tue, Mar 18, 2014 at 12:17:39AM -0400, Jeff King wrote:
> On Fri, Mar 14, 2014 at 05:09:45PM -0700, Shawn Pearce wrote:
>
> > On Fri, Mar 14, 2014 at 4:30 PM, Duy Nguyen wrote:
> > > On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce
> > > wrote:
> > >>
> > >> You missed the SSH case. It doesn't
On Tue, Mar 18, 2014 at 9:27 PM, Duy Nguyen wrote:
> I thought about "GIT_CAPABILITIES= git-upload-pack ..." (and actually
> added it in pack-protocol.txt then deleted). The thing is, if you want
> to new upload-pack, you would need new git-upload-pack at the remote
> end that must understand "git
On Sat, Mar 15, 2014 at 08:23:08AM +0700, Duy Nguyen wrote:
> > The default would start at false, and people who know their server is
> > very up-to-date can turn it on. And then when many server
> > implementations support it, flip the default to auto. And either leave
> > it there forever, or ev
On Fri, Mar 14, 2014 at 05:09:45PM -0700, Shawn Pearce wrote:
> On Fri, Mar 14, 2014 at 4:30 PM, Duy Nguyen wrote:
> > On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce wrote:
> >>
> >> You missed the SSH case. It doesn't have this slot to hide the data into.
> >
> > Right now we run this for ssh c
On Tue, Mar 11, 2014 at 8:49 AM, Jeff King wrote:
> Right, I recall the general feeling being that such a system would work,
> and the transition would be managed by a config variable like
> "remote.*.useUploadPack2". Probably with settings like:
>
> true:
> always try, but allow fall back t
On Fri, Mar 14, 2014 at 4:30 PM, Duy Nguyen wrote:
> On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce wrote:
>>
>> You missed the SSH case. It doesn't have this slot to hide the data into.
>
> Right now we run this for ssh case: "ssh git-upload-pack
> ". New client can do this instead
>
> ssh git
On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce wrote:
> On Fri, Mar 14, 2014 at 5:37 AM, Duy Nguyen wrote:
>> On Wed, Mar 12, 2014 at 3:36 AM, Jeff King wrote:
>>> If the client is limited to setting a few flags, then something like
>>> http can get away with:
>>>
>>> GET
>>> foo.git/info/ref
On Fri, Mar 14, 2014 at 5:37 AM, Duy Nguyen wrote:
> On Wed, Mar 12, 2014 at 3:36 AM, Jeff King wrote:
>> If the client is limited to setting a few flags, then something like
>> http can get away with:
>>
>> GET
>> foo.git/info/refs?service=git-upload-pack&advertise-symrefs&refspec=refs/heads/
On Wed, Mar 12, 2014 at 3:36 AM, Jeff King wrote:
> If the client is limited to setting a few flags, then something like
> http can get away with:
>
> GET
> foo.git/info/refs?service=git-upload-pack&advertise-symrefs&refspec=refs/heads/*
>
> And it does not need to worry about upload-pack2 at a
On Tue, Mar 11, 2014 at 01:25:23PM -0700, Junio C Hamano wrote:
> > Yeah, good idea. I might be misremembering some complications, but we
> > can probably do it with:
> >
> > 1. Teach the client to send an "advertise-symrefs" flag before the ref
> > advertisement.
> >
> > 2. Teach the ser
Jeff King writes:
> On Tue, Mar 11, 2014 at 12:32:37PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > I think the main flag of interest is giving an fnmatch pattern to limit
>> > the advertised refs. There could potentially be others, but I do not
>> > know of any offhand.
>>
>> O
On Tue, Mar 11, 2014 at 12:32:37PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think the main flag of interest is giving an fnmatch pattern to limit
> > the advertised refs. There could potentially be others, but I do not
> > know of any offhand.
>
> One thing that comes to mind is
Jeff King writes:
> I think the main flag of interest is giving an fnmatch pattern to limit
> the advertised refs. There could potentially be others, but I do not
> know of any offhand.
One thing that comes to mind is where symrefs point at, which we
failed to add the last time around because we
On Sun, Feb 23, 2014 at 09:44:14AM +0700, Duy Nguyen wrote:
> (Digging up an old thread about initial refs listing in git protocol)
And now I am responding to it slowly. :)
> > For that to work, the new server needs to wait for the client to
> > speak first. How would that server handle old cli
(Digging up an old thread about initial refs listing in git protocol)
On Thu, Feb 7, 2013 at 7:12 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> I think there's a simpler way to do this, which is that:
>>
>> * New clients supporting v2 of the protocol send some piece of data
>
Junio C Hamano writes:
> I am not sure about "pushing" part, but the jc/fetch-raw-sha1 topic
> (split from the main jc/hidden-refs topic) should allow your script,
> after the client learns the set of smudged object names, to ask for
>
> git fetch $there $sha1_1 $sha1_2 ...
Well, my out-of-b
Jed Brown writes:
> I believe that my use case would be well supported if git could push and
> pull unadvertised refs, as long as basic operations were not slowed down
> by the existence of a very large number of such refs.
I am not sure about "pushing" part, but the jc/fetch-raw-sha1 topic
(spl
Jeff King writes:
> If the new client can handle the old-style server's response, then the
> server can start blasting out refs (optionally after a timeout) and stop
> when the client interrupts with "hey, wait, I can speak the new
> protocol". The server just has to include "you can interrupt me
Michael Haggerty writes:
> A first weakness of your proposal is that even though the hidden refs
> are (optionally) fetchable, there is *no* way to discover them remotely
> or to bulk-download them; they would have to be retrieved one by one
> using out-of-band information. And if I understand c
On Thu, Feb 7, 2013 at 1:16 AM, Jeff King wrote:
> On Wed, Feb 06, 2013 at 04:12:10PM -0800, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason writes:
>>
>> > I think there's a simpler way to do this, which is that:
>> >
>> > * New clients supporting v2 of the protocol send some piece of data
>
On Wed, Feb 06, 2013 at 04:12:10PM -0800, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > I think there's a simpler way to do this, which is that:
> >
> > * New clients supporting v2 of the protocol send some piece of data
> >that would break old servers.
> >
> > * If that fa
Ævar Arnfjörð Bjarmason writes:
> I think there's a simpler way to do this, which is that:
>
> * New clients supporting v2 of the protocol send some piece of data
>that would break old servers.
>
> * If that fails the new client goes "oh jeeze, I guess it's an old
>server", and try agai
On Wed, Feb 06, 2013 at 11:17:06AM -0800, Junio C Hamano wrote:
> Let me help unconfuse this thread.
>
> I think the series as 8-patch series was poorly presented, and
> separating it into two will help understanding what they are about.
>
> The first three:
>
> upload-pack: share more code
>
On Wed, Feb 6, 2013 at 8:17 PM, Junio C Hamano wrote:
Maybe this should be split up into a different thread, but:
> The upload-pack-2 service sits on a port different from today's
> [...].
I think there's a simpler way to do this, which is that:
* New clients supporting v2 of the protocol sen
Michael Haggerty writes:
> On 02/06/2013 08:17 PM, Junio C Hamano wrote:
> ...
>
> Yes, the first three patches sound much more reasonable if this is the
> goal.
> ...
> I think that a more useful interim solution would be to make it easy to
> have two URLs accessing a single git repository, with
On 02/06/2013 08:55 PM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
> [...]
>> But now every time I do a "gitk --all" or "git log --decorate", the
>> output is cluttered with all of his references (most of which are just
>> old versions of references from the upstream repository that we both
>
On 02/06/2013 08:17 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty
>> wrote:
>>> Hiderefs creates a "dark" corner of a remote git repo that can hold
>>> arbitrary content that is impossible for anybody to discover but
>>> nevertheless possib
Michael Haggerty wrote:
> Scenario 1: Some providers junk up their users' repositories with
> content that is not created by the repository's owner and that the owner
> doesn't want to appear to vouch for (e.g., GitHub pull requests). These
> references might sometimes be useful to fetch, singly
Junio C Hamano wrote:
> Duy Nguyen writes:
>> On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty
>> wrote:
>>> Hiderefs creates a "dark" corner of a remote git repo
[...]
>> Or you can think hiderefs is the first step to addressing the
>> initial ref advertisment problem. The series says hidden
Duy Nguyen writes:
> On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty wrote:
>> Hiderefs creates a "dark" corner of a remote git repo that can hold
>> arbitrary content that is impossible for anybody to discover but
>> nevertheless possible for anybody to download (if they know the name of
>> a
On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty wrote:
> Hiderefs creates a "dark" corner of a remote git repo that can hold
> arbitrary content that is impossible for anybody to discover but
> nevertheless possible for anybody to download (if they know the name of
> a hidden reference). In earl
On 02/05/2013 06:27 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> I would again like to express my discomfort about this feature, which is
>> already listed as "will merge to next".
>
> Do not take "will merge to next" too literally. One major purpose
> of marking a topic as such is ex
On Tue, Feb 5, 2013 at 5:03 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Do you have any plans for something that *does* have the reduction of
>> network bandwidth as a primary goal?
>
> Uncluttering gives reduction of bandwidth anyway, so I do not see
> much point in the dist
Michael Haggerty writes:
> On 02/05/2013 09:33 AM, Jonathan Nieder wrote:
>> Michael Haggerty wrote:
>>
>>> I would again like to express my discomfort about this feature, which is
>>> already listed as "will merge to next". Frankly, I have the feeling
>>> that this feature is being steamrolled
Jonathan Nieder writes:
>> * I didn't see a response to Peff's convincing arguments that this
>> should be a client-side feature rather than a server-side feature [1].
>
> The client can't control the size of the ref advertisement. That is
> the main motivation if I understood correctly.
The an
Michael Haggerty writes:
> I would again like to express my discomfort about this feature, which is
> already listed as "will merge to next".
Do not take "will merge to next" too literally. One major purpose
of marking a topic as such is exactly to solicit comments like this
;-)
> * I didn't s
Ævar Arnfjörð Bjarmason writes:
> Do you have any plans for something that *does* have the reduction of
> network bandwidth as a primary goal?
Uncluttering gives reduction of bandwidth anyway, so I do not see
much point in the distinction you seem to be making.
> Is this what you've been workin
On Wed, Jan 30, 2013 at 7:45 PM, Junio C Hamano wrote:
> The third round.
>
> - Multi-valued variable transfer.hiderefs lists prefixes of ref
>hierarchies to be hidden from the requests coming over the
>network.
>
> - A configuration optionally allows uploadpack to accept fetch
>requ
On 02/05/2013 09:33 AM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
>> I would again like to express my discomfort about this feature, which is
>> already listed as "will merge to next". Frankly, I have the feeling
>> that this feature is being steamrolled in before a community consensus
>
Hi Michael,
Michael Haggerty wrote:
> I would again like to express my discomfort about this feature, which is
> already listed as "will merge to next". Frankly, I have the feeling
> that this feature is being steamrolled in before a community consensus
> has been reached and indeed before many
On 01/30/2013 07:45 PM, Junio C Hamano wrote:
> The third round.
>
> - Multi-valued variable transfer.hiderefs lists prefixes of ref
>hierarchies to be hidden from the requests coming over the
>network.
>
> - A configuration optionally allows uploadpack to accept fetch
>requests for
The third round.
- Multi-valued variable transfer.hiderefs lists prefixes of ref
hierarchies to be hidden from the requests coming over the
network.
- A configuration optionally allows uploadpack to accept fetch
requests for an object at the tip of a hidden ref.
Elsewhere, we discusse
42 matches
Mail list logo
