The CONNECT_DIAG_URL code for PROTO_GIT and PROTO_SSH were different in
subtle ways. Those differences are not significant enough to justify the
duplication of code, while this change also avoids starting to
initialize a connection at all when handling CONNECT_DIAG_URL.
This also moves the get_hos
Instead of having each of them (and their callees) take a host:port
string and call get_host_and_port on it on their own, rely on the
get_host_and_port that already happens in git_connect and pass down
the separate host and port strings we got out of it.
Note that in git_tcp_connect_sock, the port
Now that hostandport is left unmodified in git_connect (we don't pass
it to get_host_and_port() anymore), we can avoid xstrdup'ing it.
Signed-off-by: Mike Hommey
---
connect.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/connect.c b/connect.c
index b3fce84..e2b976e 10
get_port() is only used as a fallback when get_host_and_port() does not
return a port. But get_port() does the same search as
get_host_and_port(), except get_host_and_port() starts from the end of
the host, respecting square brackets for ipv6 addresses, and get_port(),
operating after get_host_and_
Currently, core.gitProxy doesn't actually match purely on domain names
as documented: it also matches ports.
So a core.gitProxy value like "script for kernel.org" doesn't make the
script called for an url like git://kernel.org:port/path, while it is
called for git://kernel.org/path.
This per-port
Signed-off-by: Mike Hommey
---
connect.c | 101 ++
1 file changed, 55 insertions(+), 46 deletions(-)
diff --git a/connect.c b/connect.c
index e2b976e..db78eb2 100644
--- a/connect.c
+++ b/connect.c
@@ -639,6 +639,58 @@ static enum proto
On Fri, Apr 29, 2016 at 09:58:37AM -0700, Junio C Hamano wrote:
> So I would suggest restructuring this series to do
>
> * 2/3 (DIAG consolidation)
> * refactoring in 3/3 but not s/static/extern/
>
> and in optional follow(s)-up, do
>
> * s/static/extern/ and update to *.h in 3/3
>
> * 1/3
On Sun, May 01, 2016 at 07:28:52AM +0700, Duy Nguyen wrote:
> On Wed, Apr 27, 2016 at 09:15:41AM -0700, Junio C Hamano wrote:
> > Duy Nguyen writes:
> >
> > > This patch forces bin-wrappers regeneration every time a test program
> > > is updated. A bit wasteful, but I don't see a better option (w
On Wed, Apr 27, 2016 at 09:15:41AM -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > This patch forces bin-wrappers regeneration every time a test program
> > is updated. A bit wasteful, but I don't see a better option (which is
> > also why I limit this to test programs only).
>
> In othe
On Sat, Apr 30, 2016 at 1:46 AM, David Turner wrote:
> On Thu, 2016-04-28 at 11:58 -0700, Junio C Hamano wrote:
>> David Turner writes:
>>
>> > From: Nguyễn Thái Ngọc Duy
>> > ...
>> > The biggest gain is not having to verify the trailing SHA-1, which
>> > takes lots of time especially on large
Variable named 'verbose' in builtin/commit.c is consumed by git-status
and git-commit so if a new verbose related behavior is introduced in
git-commit, then it should not affect the behavior of git-status.
One previous commit (title: commit: add a commit.verbose config
variable) introduced a new c
Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.
Helped-by: Junio C Hamano
Helped-by: Eric Sunshine
Signed-off-by: Pranit Bauva
---
The previous version of the patch are:
- [v12] $gmane/288820
- [v11] $gmane/288820
- [v10] $gmane/288820
- [v
Include tests to check for multiple levels of quiet and to check if the
'--no-quiet' option sets it to 0.
Signed-off-by: Pranit Bauva
---
Link to v14:
- $gmane/20
Changes wrt v14:
- Change the test to use '-q -q -q --no-quiet' instead of just '--no-quiet'
- Move the test for '--no-verbos
OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.
Make OPT_COUNTUP() treat any negative number as
We would want to see how multiple --quiet options affect the value of
the underlying variable (we may want "--quiet --quiet" to still be 1, or
we may want to see the value incremented to 2). Show the value as
integer to allow us to inspect it.
Signed-off-by: Pranit Bauva
---
t/t0040-parse-option
Make the fake "editor" store output of grep in a file so that we can
see how many diffs were contained in the message and use them in
individual tests where ever it is required. A subsequent commit will
introduce scenarios where it is important to be able to exactly
determine how many diffs were pr
Signed-off-by: Pranit Bauva
---
Changes wrt previous version (v12):
- Use '\' when interpolation isn't required
Signed-off-by: Pranit Bauva
---
t/t0040-parse-options.sh | 76
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/t/t00
On Tue, Apr 26, 2016 at 3:20 AM, Eric Sunshine wrote:
> On Sun, Apr 24, 2016 at 9:33 AM, Christian Couder
> wrote:
>> To libify `git apply` functionality we have to signal errors
>> to the caller instead of die()ing.
>>
>> As a first step in this direction, let's make apply_patch() return
>> -1 i
On Mon, Apr 25, 2016 at 9:50 AM, Eric Sunshine wrote:
>> @@ -4515,8 +4521,6 @@ static int write_out_results(struct apply_state
>> *state, struct patch *list)
>> return errs;
>> }
>>
>> -static struct lock_file lock_file;
>
> Does the static lock_file in build_fake_ancestor() deserve the
Hi all,
On Fri, 29 Apr 2016, Junio C Hamano wrote:
> The latest maintenance release Git v2.8.2 is now available at
> the usual places.
I considered releasing Git for Windows v2.8.2 today, too. However, I
decided to delay the release for a couple of days, for a couple of
reasons:
- I expect an u
On Sat, Apr 30, 2016 at 3:19 AM, David Aguilar wrote:
> On Wed, Apr 27, 2016 at 11:12:25AM +0200, Jan Smets wrote:
>> Hi
>>
>> Please consider following example
>>
>> #!/bin/bash
>> rm -rf /tmp/gittest
>> mkdir /tmp/gittest
>> cd /tmp/gittest
>>
>> git init
>>
>> echo $RANDOM > testfile
>> git add
Jason Vas Dias wrote:
> Thanks very much Eric & Jeff for your reply .
>
> Personally, I would recommend setting the SO_RECVTIMEO for GIT server
> sockets to a fixed default (eg. 5mins) , settable by a
> '--receive-timeout' argument or configuration parameter .
(apologies for the delay, I thoug
22 matches
Mail list logo
