git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Braun <thomas.braun@byte-physics.de>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, msysgit@googlegroups.com, kusmabite@gmail.com
Subject: Re: [PATCH/RFC] send-pack.c: Allow to disable side-band-64k
Date: Mon, 19 May 2014 23:15:00 +0200	[thread overview]
Message-ID: <537A7454.6030001@byte-physics.de> (raw)
In-Reply-To: <20140519193340.GP12314@google.com>

Am 19.05.2014 21:33, schrieb Jonathan Nieder:
> Hi,
>
> Thomas Braun wrote:
>
>> pushing over the dump git protocol with a windows git client.
>
> I've never heard of the dump git protocol.  Do you mean the git
> protocol that's used with git:// URLs?

You are right I mean the protocol involving git:// URLs. But 
unfortunately I got it wrong as according to [1] the git:// is one of 
the so-called smart protocols. That was also the source where I read 
that there are smart and dump protocols.

[1]: http://git-scm.com/book/en/Git-Internals-Transfer-Protocols

> [...]
>> Alternative approaches considered but deemed too invasive:
>> - Rewrite read/write wrappers in mingw.c in order to distinguish between
>>    a file descriptor which has a socket behind and a file descriptor
>>    which has a file behind.
>
> I assume here "too invasive" means "too much engineering effort"?
>
> It sounds like a clean fix, not too invasive at all.  But I can
> understand wanting a stopgap in the meantime.

No actually I meant too invasive in the sense of "requiring large 
rewrites which only benefit git on windows and hurt all others".

The two fixes I can think of either involve:
- In a read *and* write wrapper the need to check if the fd is a socket, 
if yes use send/recv if no use read/write. According to Erik's comments 
this should be possible. But I would deem the expected performance 
penalty quite large as that will be done in every call.
- Rewriting read/write to accept windows handles instead of file 
descriptors. Only a theoretical option IMHO.

For me the goal is also to minimise the diff between git and msysgit/git.

>
>> - Turning the capability side-band-64k off completely. This would remove a useful
>>    feature for users of non-affected transport protocols.
>
> Would it make sense to turn off sideband unconditionally on Windows
> when using the relevant protocols?
>

Yes, if this would be also acceptable for git.git.

I can check at the call site of send_pack in transport.c what protocol 
is in use, and then pass a new parameter use_sideband to it.
Or maybe "adapt" server_capabilities in connect.c to not include 
side-band-64k if using git:// ?


-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

  parent reply	other threads:[~2014-05-19 21:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-19 19:07 [PATCH/RFC] send-pack.c: Allow to disable side-band-64k Thomas Braun
2014-05-19 19:33 ` Jonathan Nieder
2014-05-19 20:00   ` Erik Faye-Lund
2014-05-19 20:29     ` Erik Faye-Lund
2014-05-20  8:46       ` Thomas Braun
2014-05-20  9:01         ` Erik Faye-Lund
2014-05-19 21:15   ` Thomas Braun [this message]
2014-05-19 21:20     ` Erik Faye-Lund

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

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

  git send-email \
    --in-reply-to=537A7454.6030001@byte-physics.de \
    --to=thomas.braun@byte-physics.de \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=kusmabite@gmail.com \
    --cc=msysgit@googlegroups.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.
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 NNTP newsgroup(s).