Understood (and agree).
We do use git for source code (where we use SSH
and key authentication for CI/CD), but also for
configuration control of other files like
financial reports, engineering drawings, etc.
where access is via HTTPS. In that 2nd group the
challenge is to make it as "not cod
On 2019-10-17 at 14:33:38, Ralph Ewig wrote:
> Quick follow up question: can the git client pass
> a token read from a cookie with a request? That
> would enable users to sign-in via a browser, store
> the cookie, and then use that as the access token
> to authenticate a git request.
Git has an op
Quick follow up question: can the git client pass
a token read from a cookie with a request? That
would enable users to sign-in via a browser, store
the cookie, and then use that as the access token
to authenticate a git request.
On 10/16/2019 11:03 PM, Jeff King wrote:
> On Thu, Oct 17, 2019
Interesting ... I have not looked at access tokens
before, but did find some documentation online
that describes how Azure AD Jason Web Tokens can
be used to authenticate a headless API
(https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens),
This seems to be a fit in thi
On Thu, Oct 17, 2019 at 03:00:58AM +, Ralph Ewig wrote:
> Thanks for the reply. I was hoping the Git GUI
> might be able to handle the OpenID authentication
> flow, but it makes sense that it would be
> inconsistent with other git clients.
I don't think we'd ever do the full flow, but it m
Thanks for the reply. I was hoping the Git GUI
might be able to handle the OpenID authentication
flow, but it makes sense that it would be
inconsistent with other git clients.
Azure AD does support both LDAP and Kerberos, but
unfortunately only as an extra cost add-on called
"Domain Services"
On 2019-10-15 at 15:59:03, Ralph Ewig wrote:
> Hi Everyone, hoping you might have a solution for
> this problem:
>
> CONTEXT
>
> * I'm serving git repos using "smart https" via
> apache and basic authentication; everything works
> fine.
> * We're moving to SSO via Azure AD and apache
> mo
Hi Everyone, hoping you might have a solution for
this problem:
CONTEXT
* I'm serving git repos using "smart https" via
apache and basic authentication; everything works
fine.
* We're moving to SSO via Azure AD and apache
mod_auth_openidc; this works fine for gitweb (on
the same server a
Jeff King writes:
> Yep. Here it is.
>
> Rather than a range-diff, which is quite large due to the code movement,
> I'll include below the interesting hunk of a diff between the two
> endpoints (i.e., what we would have seen applying the packet-err-check
> changes on top of my code movement, whic
On Wed, Feb 06, 2019 at 11:29:03AM -0800, Josh Steadmon wrote:
> > + packet_reader_init(&reader, -1, d->buf, d->len,
> > + PACKET_READ_CHOMP_NEWLINE |
> > + PACKET_READ_DIE_ON_ERR_PACKET);
> > + if (packet_reader_read(&reader) != PACKET_READ_NORMAL)
>
Josh Steadmon writes:
>> +packet_reader_init(&reader, -1, d->buf, d->len,
>> + PACKET_READ_CHOMP_NEWLINE |
>> + PACKET_READ_DIE_ON_ERR_PACKET);
>> +if (packet_reader_read(&reader) != PACKET_READ_NORMAL)
>> +die("invalid server respon
On 2019.02.06 14:18, Jeff King wrote:
> After making initial contact with an http server, we have to decide if
> the server supports smart-http, and if so, which version. Our rules are
> a bit inconsistent:
>
> 1. For v0, we require that the content-type indicates a smart-http
In a v2 smart-http conversation, the server should reply to our initial
request with a pkt-line saying "version 2". We check that with
starts_with(), but really that should be the only thing in that packet.
A response of "version 20" should not match.
Let's tighten
After making initial contact with an http server, we have to decide if
the server supports smart-http, and if so, which version. Our rules are
a bit inconsistent:
1. For v0, we require that the content-type indicates a smart-http
response. We also require the response to look vaguely like
On Tue, Feb 05, 2019 at 03:29:18PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > After making initial contact with an http server, we have to decide if
> > the server supports smart-http, and if so, which version. Our rules are
> > a bit inconsistent:
&
Jeff King writes:
> After making initial contact with an http server, we have to decide if
> the server supports smart-http, and if so, which version. Our rules are
> a bit inconsistent:
> ...
>
> - we now predicate the smart/dumb decision entirely on the presence of
>
Josh Steadmon writes:
> This is a reroll of js/smart-http-detect-remote-error that also includes
> a fixed version of ms/proto-err-packet-anywhere [1].
Yay. Thanks for reducing a topic I have to worry about by 1 ;-).
> The first patch clarifies the use of ERR messages in the
This is a reroll of js/smart-http-detect-remote-error that also includes
a fixed version of ms/proto-err-packet-anywhere [1].
The first patch clarifies the use of ERR messages in the pkt-line
protocol and unifies error handling in pkt-line.c
The second patch refactors smart-http discovery in
From: Jeff King
After making initial contact with an http server, we have to decide if
the server supports smart-http, and if so, which version. Our rules are
a bit inconsistent:
1. For v0, we require that the content-type indicates a smart-http
response. We also require the response to
From: Jeff King
In a v2 smart-http conversation, the server should reply to our initial
request with a pkt-line saying "version 2" (this is the start of the
"capabilities advertisement"). We check for the string using
starts_with(), but that's overly permissive (it woul
On 2018.11.16 03:48, Jeff King wrote:
> In a v2 smart-http conversation, the server should reply to our initial
> request with a pkt-line saying "version 2" (this is the start of the
> "capabilities advertisement"). We check for the string using
> starts_with(),
On 2018.11.16 03:47, Jeff King wrote:
> After making initial contact with an http server, we have to decide if
> the server supports smart-http, and if so, which version. Our rules are
> a bit inconsistent:
>
> 1. For v0, we require that the content-type indicates a smart-http
On 2018.11.16 03:44, Jeff King wrote:
[...]
> Amusingly, this does break the test you just added, because it tries to
> issue an ERR after claiming "text/html" (and after my patch, we
> correctly fall back to dumb-http).
Heh yeah, I copied the script from a dumb-http test without reading the
spec.
In a v2 smart-http conversation, the server should reply to our initial
request with a pkt-line saying "version 2" (this is the start of the
"capabilities advertisement"). We check for the string using
starts_with(), but that's overly permissive (it would match "ver
After making initial contact with an http server, we have to decide if
the server supports smart-http, and if so, which version. Our rules are
a bit inconsistent:
1. For v0, we require that the content-type indicates a smart-http
response. We also require the response to look vaguely like
>
> For the first point above, dumb servers should never use an
> "application/x-git-*" content type (http-protocol.txt line 163-167).
>
> For the second point, the docs require v2 servers to use
> "application/x-git-*" content types. protocol-v2.txt lines 63-65 s
On Sat, Mar 03, 2018 at 03:28:47AM -0500, Eric Sunshine wrote:
> On Sat, Mar 3, 2018 at 12:27 AM, Jeff King wrote:
> > Subject: smart-http: document flush after "# service" line
> >
> > The http-protocol.txt spec fails to mention that a flush
> > packet com
On Sat, Mar 3, 2018 at 12:27 AM, Jeff King wrote:
> Subject: smart-http: document flush after "# service" line
>
> The http-protocol.txt spec fails to mention that a flush
> packet comes in the smart server response after sending any
> the "service" header.
&
not forthcoming, then. :-/
Let's wrap up this topic with this, then, which adds a commit message
and fixes the flush/version-1 ordering issue.
-- >8 --
Subject: smart-http: document flush after "# service" line
The http-protocol.txt spec fails to mention that a flush
packet comes in
Bryan Turner writes:
> That means if you pair a pre-receive hook with Git 2.11 or newer on
> the server, you should be able to achieve what you're looking for.
It probably is worth mentioning that even without the "quarantine"
changes of 2.11, the new objects brought in by a rejected push
cannot
On Sat, May 6, 2017 at 5:30 AM, akos tajti wrote:
> Dear All,
>
> we implemented a java servlet around the git-http-backend. This servlet
> intercepts the requests sent by the git client when pushing. One thing I want
> to achieve is parsing the commit messages in the pre push phase (request
>
Dear All,
we implemented a java servlet around the git-http-backend. This servlet
intercepts the requests sent by the git client when pushing. One thing I want
to achieve is parsing the commit messages in the pre push phase (request param
service==git-receive-pack) and after checking if the com
Thank you for your reply Jeff. I have moved on to installing GitLab. It has
been a success so far.
Thanks,
Dave
-Original Message-
From: Jeff King [mailto:p...@peff.net]
Sent: Wednesday, August 24, 2016 1:00 PM
To: David McGough
Cc: git@vger.kernel.org
Subject: Re: Smart HTTP push
tty confused about what the issue. Which OS user is git
> using to write the files? I hope somebody can help me understand why
> the project cannot be pushed to the git server.
For a smart-http push, it will be whatever user the web server execs the
CGI as. So I'd think "apac
Hi Git Community!
I'm trying to get Git on the server. I installed Git and httpd on Centos 7 and
configred for smart http. I created a project on my local git and I cloned it
to a base repository:
git clone --bare DataConversion DataConversion.git then I scp it to the server:
s
On do, 2016-03-10 at 10:13 -0300, Ben Mezger wrote:
> The git-scm.com only uses apache2 as an example of setting Git's
> Smart
> HTTP, and searching the web for the Nginx's config only gives me old
> configs or not-functional configurations. Has anyone managed to get
>
Hi all,
The git-scm.com only uses apache2 as an example of setting Git's Smart
HTTP, and searching the web for the Nginx's config only gives me old
configs or not-functional configurations. Has anyone managed to get
Smart HTTP to work with Nginx and could give me a sample of the .conf
On Sat, Jul 11, 2015 at 11:26 AM, Ilari Liusvaara
wrote:
> On Sat, Jul 11, 2015 at 10:23:09AM -0700, Shawn Pearce wrote:
>>
>> > Websockets over HTTP/2 (a.k.a. "websockets2") has not been defined yet.
>> > With Websockets(1), it would probably already be possible to tunnel the
>> > native git smar
ficult to speed up (due to nature of the negotiations),
> > but usually is pretty reliable (the efficiency isn't horrible).
>
> The negotiation in smart-HTTP actually has some bad corner cases. Each
> round of negotiation requires a new POST resupplying all previously
> agr
On Sat, Jul 11, 2015 at 12:00 AM, Ilari Liusvaara
wrote:
> On Sat, Jul 11, 2015 at 11:10:48AM +0800, ForceCharlie wrote:
>> As we known, HTTP/2.0 has been released. All Git-Smart-HTTP are currently
>> implemented using HTTP/1.1.
>
> Nit: It is HTTP/2.
>
>> Freque
On Sat, Jul 11, 2015 at 11:10:48AM +0800, ForceCharlie wrote:
> As we known, HTTP/2.0 has been released. All Git-Smart-HTTP are currently
> implemented using HTTP/1.1.
Nit: It is HTTP/2.
> Frequently used Git developers often feel Git HTTP protocol is not
> satisfactory, slow and u
As we known, HTTP/2.0 has been released. All Git-Smart-HTTP are currently
implemented using HTTP/1.1.
Frequently used Git developers often feel Git HTTP protocol is not
satisfactory, slow and unstable.This is because the HTTP protocol itself
decides
When HTTP/2.0 is published. We might be able to
.sh
> +++ b/t/t5551-http-fetch-smart.sh
> @@ -213,6 +213,17 @@ test_expect_success 'cookies stored in http.cookiefile
> when http.savecookies set
> test_cmp expect_cookies.txt cookies_tail.txt
> '
>
> +test_expect_success 'transfer.hi
On Fri, Mar 13, 2015 at 11:59 AM, Jeff King wrote:
> On Fri, Mar 13, 2015 at 12:41:01AM -0400, Jeff King wrote:
>
>> I'm experimenting with using transfer.hiderefs on a server, and it's
>> rather easy to cause a git client to hang when fetching from such a repo
>&g
On Fri, Mar 13, 2015 at 12:41:01AM -0400, Jeff King wrote:
> I'm experimenting with using transfer.hiderefs on a server, and it's
> rather easy to cause a git client to hang when fetching from such a repo
> over smart http. Details are in the first patch.
A note on this ha
in http.cookiefile
when http.savecookies set
test_cmp expect_cookies.txt cookies_tail.txt
'
+test_expect_success 'transfer.hiderefs works over smart-http' '
+ test_commit hidden &&
+ test_commit visible &&
+ git push public HEAD^:refs/heads
I'm experimenting with using transfer.hiderefs on a server, and it's
rather easy to cause a git client to hang when fetching from such a repo
over smart http. Details are in the first patch.
There are 7 patches here, but the entirety of the fix is contained in
the first one. The rest ar
On Wed, Nov 05, 2014 at 07:11:29PM +, Jonathan wrote:
> The client can connect to and successfully fetch the repo from the
> server over https. However, when trying to push egit gives the error
> "remote does not support http push." When attempting a push via bash,
> I get "return code 22 - fa
This is yet another smart http thread. I must have read dozens of threads and
articles about setting this up but everyone seems to do it a little differently
so I can't tell what's right and what's not. First up, the environment, which
is the same for both server and test clien
On Mon, 13 Oct 2014 17:29:05 +
"John Norris" wrote:
> I guess this comment is aimed at Scott Chacon.
> I have read your blog post on Smart HTTP
> (http://git-scm.com/blog/2010/03/04/smart-http.html) and wondered if
> there is any documentation that compares in terms
Hi,
I guess this comment is aimed at Scott Chacon.
I have read your blog post on Smart HTTP
(http://git-scm.com/blog/2010/03/04/smart-http.html) and wondered if
there is any documentation that compares in terms of thoroughness with
your sections in the book on using SSH, which does explain the
helper_option(), and the helper needs to take necessary action.
For the smart-HTTP helper, the "necessary action" involves spawning
the "git send-pack" subprocess with the "--signed" option.
Once the above all gets wired in, the smart-HTTP transport now can
use the pus
Currently it seems that somewhere in the transport option setting
chain the "--signed" bit gets lost and this does not pass.
Signed-off-by: Junio C Hamano
---
t/t5541-http-push-smart.sh | 39 +++
1 file changed, 39 insertions(+)
diff --git a/t/t5541-http-push
You need to allow the directory to be read?
Allow from all
--
View this message in context:
http://git.661346.n2.nabble.com/PROPFIND-405-with-git-http-backend-and-Smart-HTTP-tp7564017p7616843.html
Sent from the git mailing list archive at Nabble.com.
--
To
.8.3, git will show text/plain content sent along with a
a non-200 HTTP code.
However, it does this _only_ for the initial refs fetch (along with
several other error-reporting niceties, including specifically handling
HTTP 401s). The thinking was that the interesting smart-http errors
happen on that i
On Mon, 2014-05-19 at 18:12 +1000, Bryan Turner wrote:
> On Sat, May 17, 2014 at 9:01 AM, brian m. carlson
> wrote:
> > On Tue, May 13, 2014 at 09:39:59AM +0200, "Ákos, Tajti" wrote:
> >> Dear List,
> >>
> >> we implemented our own git smart
On Sat, May 17, 2014 at 9:01 AM, brian m. carlson
wrote:
> On Tue, May 13, 2014 at 09:39:59AM +0200, "Ákos, Tajti" wrote:
>> Dear List,
>>
>> we implemented our own git smart http server to be able to check permissions
>> and other thing before pushes. It wo
On Tue, May 13, 2014 at 09:39:59AM +0200, "Ákos, Tajti" wrote:
> Dear List,
>
> we implemented our own git smart http server to be able to check permissions
> and other thing before pushes. It works fine, however, the error messages we
> generate on the server side
Dear List,
we implemented our own git smart http server to be able to check
permissions and other thing before pushes. It works fine, however, the
error messages we generate on the server side are not displayed by the
command line client. On the server we generate error messages like this
Duy Nguyen writes:
> On Fri, Feb 07, 2014 at 10:01:08AM -0800, Junio C Hamano wrote:
>> Here is the difference between the posted series and what I queued
>> after applying the changes suggested during the review.
>>
>> Thanks.
>
> I was going to send a reroll after the received comments. Could
On Fri, Feb 07, 2014 at 10:01:08AM -0800, Junio C Hamano wrote:
> Here is the difference between the posted series and what I queued
> after applying the changes suggested during the review.
>
> Thanks.
I was going to send a reroll after the received comments. Could you
put this on top of 6/6, ju
least one common base and multi_ack or
multi_ack_detailed is enabled. The server always sends NAK after 'done'
if there is no common base found.
diff --git a/Documentation/technical/protocol-capabilities.txt
b/Documentation/technical/protocol-capabilities.txt
index cb2f5eb..e174343 100644
--
On Fri, Feb 7, 2014 at 2:16 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> In smart http, upload-pack adds new shallow lines at the beginning of
>> each rpc response. Only shallow lines from the first rpc call are
>> useful. After that they are thrown away
On Thu, Feb 06, 2014 at 10:10:39PM +0700, Nguyễn Thái Ngọc Duy wrote:
> In smart http, upload-pack adds new shallow lines at the beginning of
> each rpc response. Only shallow lines from the first rpc call are
> useful. After that they are thrown away. It's designed this way
> be
On Thu, Feb 6, 2014 at 10:10 AM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
> index b0fa738..fb11073 100755
> --- a/t/t5537-fetch-shallow.sh
> +++ b/t/t5537-fetch-shallow.sh
> @@ -200,5 +200,29 @@ EOF
> )
> '
>
> +# This test is tricky.
Nguyễn Thái Ngọc Duy writes:
> In smart http, upload-pack adds new shallow lines at the beginning of
> each rpc response. Only shallow lines from the first rpc call are
> useful. After that they are thrown away. It's designed this way
> because upload-pack is stateless and has
In smart http, upload-pack adds new shallow lines at the beginning of
each rpc response. Only shallow lines from the first rpc call are
useful. After that they are thrown away. It's designed this way
because upload-pack is stateless and has no idea when its shallow
lines are helpful or not
On Thu, Dec 05, 2013 at 08:02:50PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/gitremote-helpers.txt | 7 +++
> builtin/fetch-pack.c| 16 +---
> remote-curl.c | 31 ++
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitremote-helpers.txt | 7 +++
builtin/fetch-pack.c| 16 +---
remote-curl.c | 31 +--
t/t5536-fetch-shallow.sh| 27 +++
tran
On Wed, Dec 04, 2013 at 03:28:00PM -0800, Jonathan Nieder wrote:
> For what it's worth, when I build git and run tests I tend to be in an
> environment with apache available, but I'm too lazy to configure git's
> tests to pick the right port and make sure it is reserved and so on.
> Perhaps there'
r test harness apache config has grown
non-trivial).
> As long as a server supports bog standard CGI interface, smart-http
> should work the same way with any such server. For that reason, it
> should be theoretically sufficient to test with one non-apache
> server (i.e. mongoose) for th
On Thu, Dec 5, 2013 at 6:28 AM, Jonathan Nieder wrote:
> Jeff King wrote:
>
>> I don't know if it is worth all that much effort, though. I suppose it
>> could get us more exposure to the httpd tests, but I do not know if it
>> would be a good idea to turn them on by default anyway. They touch
>> g
Jeff King wrote:
> I don't know if it is worth all that much effort, though. I suppose it
> could get us more exposure to the httpd tests, but I do not know if it
> would be a good idea to turn them on by default anyway. They touch
> global machine resources (like ports) that can cause conflicts o
g an
excuse "my box does not have apache installed" from them.
As long as a server supports bog standard CGI interface, smart-http
should work the same way with any such server. For that reason, it
should be theoretically sufficient to test with one non-apache
server (i.e. mongoose) for t
On Wed, Dec 04, 2013 at 12:09:09PM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > I was thinking of an alternative to apache for testing smart-http
> > so that most of http tests could always run. Mongoose [1] looks
> > like a good candidate to bundle with git.
Duy Nguyen writes:
> I was thinking of an alternative to apache for testing smart-http
> so that most of http tests could always run. Mongoose [1] looks
> like a good candidate to bundle with git. Just one pair of source
> files, mongoose.[ch], a mainloop wrapper and we have an h
On Wed, Dec 04, 2013 at 10:13:11AM -0800, Shawn Pearce wrote:
> On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen wrote:
> > I was thinking of an alternative to apache for testing smart-http so
> > that most of http tests could always run. Mongoose [1] looks like a
> > good candida
On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen wrote:
> I was thinking of an alternative to apache for testing smart-http so
> that most of http tests could always run. Mongoose [1] looks like a
> good candidate to bundle with git. Just one pair of source files,
> mongoose.[ch], a main
I was thinking of an alternative to apache for testing smart-http so
that most of http tests could always run. Mongoose [1] looks like a
good candidate to bundle with git. Just one pair of source files,
mongoose.[ch], a mainloop wrapper and we have an http server. Just
wondering, do we rely on any
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-fetch-pack.txt| 4
Documentation/gitremote-helpers.txt | 3 +++
builtin/fetch-pack.c| 7 +++
remote-curl.c | 14 +-
t/t5551-http-fetch.sh | 9 +
tran
On Tue, Aug 20, 2013 at 9:16 PM, Jeff King wrote:
> On Tue, Aug 20, 2013 at 12:08:08PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> This may provide some clues for those who want to modify smart http
>> code as smart http is pretty much undocumented. Smart http "document&quo
On Tue, Aug 20, 2013 at 12:08:08PM +0700, Nguyen Thai Ngoc Duy wrote:
> This may provide some clues for those who want to modify smart http
> code as smart http is pretty much undocumented. Smart http "document"
> so far is a few commit messages and the source code.
There was
This may provide some clues for those who want to modify smart http
code as smart http is pretty much undocumented. Smart http "document"
so far is a few commit messages and the source code.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-fetch-pack.txt
We have been passing enough information to enable the
compare-and-swap logic down to the transport layer, but the
transport helper was not passing it to smart-http transport.
Signed-off-by: Junio C Hamano
---
* I didn't bother with the dumb commit walker push for obvious
reasons, b
The push() method in remote-curl.c is not told and does not pass the
necessary information to underlying send-pack, so this extension
does not yet work. Leave a note in the test suite.
Signed-off-by: Junio C Hamano
---
* This is primarily to give a target for other people to shoot at;
patch
This is an extension of c6807a4 (clone: open a shortcut for
connectivity check - 2013-05-26) to reduce the cost of connectivity
check at clone time, this time with smart http protocol.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-fetch-pack.txt| 4
Documentation/gitremote
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/technical/pack-protocol.txt | 3 +++
builtin/fetch-pack.c | 3 +--
remote-curl.c | 4 +++-
t/t5536-fetch-shallow.sh | 27 +++
upload-pack.c
t, and the list must end with a flush
packet.
--no-progress::
Do not show the progress.
+--stateless-rpc::
+ Smart HTTP mode.
+
+--lock-pack::
+ Issue "lock" command to the remote helper via stdout.
+
-v::
Run verbosely.
diff --git a/Documentation/git-rec
/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -551,3 +551,69 @@ An example client/server communication might look like
this:
S: 0018ok refs/heads/debug\n
S: 002ang refs/heads/master non-fast-forward\n
+
+Smart HTTP Transport
On Sun, Feb 17, 2013 at 04:54:43PM -0800, Jonathan Nieder wrote:
> > My intent was that it followed the error convention of "negative is
> > error, 0 is success, and positive is not used, but reserved for
> > future use".
>
> From a maintainability perspective, that kind of contract would be
> da
Jeff King wrote:
> On Sun, Feb 17, 2013 at 02:49:39AM -0800, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> --- a/remote-curl.c
[...]
>>> + if (read_packets_until_flush(&last->buf, &last->len) < 0)
>>
>> Style nit: this made me wonder "What would it mean if
>> read_packets_until_flush()
le error;
>
> easier to read.
My intent was that it followed the error convention of "negative is
error, 0 is success, and positive is not used, but reserved for
future use". And I tend to think the "< 0" makes it obvious that we are
interested in e
n for this
function is "0 for success", I would personally find
if (read_packets_until_flush(...))
handle error;
easier to read.
> + die("smart-http metadata lines are invalid at %s",
> + refs_url
A smart http ref advertisement starts with a packet
containing the service header, followed by an arbitrary
number of packets containing other metadata headers,
followed by a flush packet.
We don't currently recognize any other metadata headers, so
we just parse through any extra pa
For the most part, smart-http just passes data to fetch-pack and
send-pack, which take care of the heavy lifting. However, I did find a
few corner cases around truncated data from the server, one of which can
actually cause a deadlock.
I found these because I was trying to figure out what was
On Wed, Feb 06, 2013 at 07:56:08AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Is it worth having a strbuf_set* family of functions to match the
> > strbuf_add*? We seem to have these sorts of errors with strbuf from time
> > to time, and I wonder if that would make it easier (and mor
Jeff King writes:
> Is it worth having a strbuf_set* family of functions to match the
> strbuf_add*? We seem to have these sorts of errors with strbuf from time
> to time, and I wonder if that would make it easier (and more readable)
> to do the right thing.
Possibly.
The callsite below may be
On Wed, Feb 06, 2013 at 11:24:41AM +0100, Michael Schubert wrote:
> On 01/31/2013 11:09 PM, Junio C Hamano wrote:
>
> >
> > -static int http_request_reauth(const char *url, void *result, int target,
> > +static int http_request_reauth(const char *url,
> > + struct strbu
;
> @@ -113,7 +115,7 @@ static struct discovery* discover_refs(const char
> *service)
> }
> refs_url = strbuf_detach(&buffer, NULL);
>
> - http_ret = http_get_strbuf(refs_url, &buffer, HTTP_NO_CACHE);
> + http_ret = http_get_strbuf(refs_url,
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -158,9 +158,8 @@ test_expect_success 'GIT_SMART_HTTP can disable smart http'
'
'
test_expect_success 'invalid Content-Type rejected' '
- echo "fatal: invalid content-type text/html
1 - 100 of 145 matches
Mail list logo
