* ls-remote bug
[not found] <BL0PR18MB2130C672D503E49F955E04E8BADFA@BL0PR18MB2130.namprd18.prod.outlook.com>
@ 2023-10-24 10:55 ` Lior Zeltzer
2023-10-27 1:08 ` Bagas Sanjaya
0 siblings, 1 reply; 6+ messages in thread
From: Lior Zeltzer @ 2023-10-24 10:55 UTC (permalink / raw)
To: git@vger.kernel.org
>uname -a
Linux dc3lp-veld0045 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Gerrit version :
3.8.0
Bug description :
When running ls-remote : sometime data gets cut in the middle
Reproducing :
You need a few files with a few repo names (I used 4 files with 10 repos each)
Call then l1..l4
And the code below just cd into each of them does ls-remote twice and compares the data
Doing it in parallel on all lists.
Data received in both ls-remotes should be the same , if not, it prints ***
Repos should contain a lot of tags and refs
Note :
1. without stderr redirection (2>&1) all works well
2. On local repos (not through gerrit) all works well
I compared various git vers and found the bug to be between 2.31.8 and 2.32.0
Comparing ls-remote.c file between those vers gave me :
Lines :
if (transport_disconnect(transport))
return 1;
moved to end of sub
copying ls-remote.c from 2.31.8 to 2.32.0 - fixed the bug
Code reproducing bug :
#!/proj/mislcad/areas/DAtools/tools/perl/5.10.1/bin/perl -w
use strict;
use Cwd qw(cwd);
my $count = 4;
for my $f (1..$count) {
my $child = fork();
if (!$child) {
my $curr = cwd();
my @repos = `cat l$f`;
foreach my $repo (@repos) {
chomp $repo;
print "$repo\n";
chdir($repo);
my $remote_tags_str = `git ls-remote 2>&1`;
my $remote_tags_str2 = `git ls-remote 2>&1 `;
chdir($curr);
if ( $remote_tags_str ne $remote_tags_str2) {
print "***\n";
}
}
exit(0);
}
}
while (wait != -1) {}
1;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ls-remote bug
2023-10-24 10:55 ` ls-remote bug Lior Zeltzer
@ 2023-10-27 1:08 ` Bagas Sanjaya
2023-10-27 11:16 ` [EXT] " Lior Zeltzer
0 siblings, 1 reply; 6+ messages in thread
From: Bagas Sanjaya @ 2023-10-27 1:08 UTC (permalink / raw)
To: Lior Zeltzer, Git Mailing List
Cc: Andrzej Hunt, Ævar Arnfjörð Bjarmason,
Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]
On Tue, Oct 24, 2023 at 10:55:24AM +0000, Lior Zeltzer wrote:
>
> >uname -a
> Linux dc3lp-veld0045 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>
> Gerrit version :
> 3.8.0
>
> Bug description :
> When running ls-remote : sometime data gets cut in the middle
>
> Reproducing :
> You need a few files with a few repo names (I used 4 files with 10 repos each)
> Call then l1..l4
> And the code below just cd into each of them does ls-remote twice and compares the data
> Doing it in parallel on all lists.
> Data received in both ls-remotes should be the same , if not, it prints ***
> Repos should contain a lot of tags and refs
What repo did you find this regression? Did you mean linux.git (Linux kernel)?
>
> Note :
> 1. without stderr redirection (2>&1) all works well
> 2. On local repos (not through gerrit) all works well
>
> I compared various git vers and found the bug to be between 2.31.8 and 2.32.0
> Comparing ls-remote.c file between those vers gave me :
>
> Lines :
> if (transport_disconnect(transport))
> return 1;
>
> moved to end of sub
>
> copying ls-remote.c from 2.31.8 to 2.32.0 - fixed the bug
>
>
>
> Code reproducing bug :
>
> #!/proj/mislcad/areas/DAtools/tools/perl/5.10.1/bin/perl -w
> use strict;
> use Cwd qw(cwd);
>
> my $count = 4;
> for my $f (1..$count) {
> my $child = fork();
> if (!$child) {
> my $curr = cwd();
>
> my @repos = `cat l$f`;
> foreach my $repo (@repos) {
> chomp $repo;
> print "$repo\n";
> chdir($repo);
> my $remote_tags_str = `git ls-remote 2>&1`;
> my $remote_tags_str2 = `git ls-remote 2>&1 `;
> chdir($curr);
> if ( $remote_tags_str ne $remote_tags_str2) {
> print "***\n";
> }
> }
>
> exit(0);
> }
> }
> while (wait != -1) {}
> 1;
>
I tried reproducing this regression by:
```
$ cd /path/to/git.git
$ git ls-remote 2>&1 > /tmp/root.list
$ cd builtin/
$ git ls-remote 2>&1 > /tmp/builtin.list
$ cd ../
$ git diff --no-index /tmp/root.list /tmp/builtin.list
```
And indeed, the diff was empty (which meant that both listings are same).
Confused...
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [EXT] Re: ls-remote bug
2023-10-27 1:08 ` Bagas Sanjaya
@ 2023-10-27 11:16 ` Lior Zeltzer
2023-10-29 18:56 ` René Scharfe
0 siblings, 1 reply; 6+ messages in thread
From: Lior Zeltzer @ 2023-10-27 11:16 UTC (permalink / raw)
To: Bagas Sanjaya, Git Mailing List
Cc: Andrzej Hunt, Ævar Arnfjörð Bjarmason,
Junio C Hamano
The reproduction ,as I wrote in the code, should be done with few threads in parallel
Each working on a list of ~10 repos with each repo containing a lot of refs/tags (~1000)
All this should be against gerrit (my gerrit is 3.8.0)
Also read the notes below regarding the code that was moved between 2.31.8 and 2.32.0 in ls-remote.c file
I can elaborate more, in a zoom meeting.
10x
Lior.
-----Original Message-----
From: Bagas Sanjaya <bagasdotme@gmail.com>
Sent: Friday, October 27, 2023 4:08 AM
To: Lior Zeltzer <liorz@marvell.com>; Git Mailing List <git@vger.kernel.org>
Cc: Andrzej Hunt <ajrhunt@google.com>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>; Junio C Hamano <gitster@pobox.com>
Subject: [EXT] Re: ls-remote bug
External Email
----------------------------------------------------------------------
On Tue, Oct 24, 2023 at 10:55:24AM +0000, Lior Zeltzer wrote:
>
> >uname -a
> Linux dc3lp-veld0045 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16
> 18:28:22 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>
> Gerrit version :
> 3.8.0
>
> Bug description :
> When running ls-remote : sometime data gets cut in the middle
>
> Reproducing :
> You need a few files with a few repo names (I used 4 files with 10
> repos each) Call then l1..l4 And the code below just cd into each of
> them does ls-remote twice and compares the data Doing it in parallel
> on all lists.
> Data received in both ls-remotes should be the same , if not, it
> prints *** Repos should contain a lot of tags and refs
What repo did you find this regression? Did you mean linux.git (Linux kernel)?
>
> Note :
> 1. without stderr redirection (2>&1) all works well 2. On local repos
> (not through gerrit) all works well
>
> I compared various git vers and found the bug to be between 2.31.8 and
> 2.32.0 Comparing ls-remote.c file between those vers gave me :
>
> Lines :
> if (transport_disconnect(transport))
> return 1;
>
> moved to end of sub
>
> copying ls-remote.c from 2.31.8 to 2.32.0 - fixed the bug
>
>
>
> Code reproducing bug :
>
> #!/proj/mislcad/areas/DAtools/tools/perl/5.10.1/bin/perl -w use
> strict; use Cwd qw(cwd);
>
> my $count = 4;
> for my $f (1..$count) {
> my $child = fork();
> if (!$child) {
> my $curr = cwd();
>
> my @repos = `cat l$f`;
> foreach my $repo (@repos) {
> chomp $repo;
> print "$repo\n";
> chdir($repo);
> my $remote_tags_str = `git ls-remote 2>&1`;
> my $remote_tags_str2 = `git ls-remote 2>&1 `;
> chdir($curr);
> if ( $remote_tags_str ne $remote_tags_str2) {
> print "***\n";
> }
> }
>
> exit(0);
> }
> }
> while (wait != -1) {}
> 1;
>
I tried reproducing this regression by:
```
$ cd /path/to/git.git
$ git ls-remote 2>&1 > /tmp/root.list
$ cd builtin/
$ git ls-remote 2>&1 > /tmp/builtin.list $ cd ../ $ git diff --no-index /tmp/root.list /tmp/builtin.list ```
And indeed, the diff was empty (which meant that both listings are same).
Confused...
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [EXT] Re: ls-remote bug
2023-10-27 11:16 ` [EXT] " Lior Zeltzer
@ 2023-10-29 18:56 ` René Scharfe
2023-10-30 8:17 ` Lior Zeltzer
0 siblings, 1 reply; 6+ messages in thread
From: René Scharfe @ 2023-10-29 18:56 UTC (permalink / raw)
To: Lior Zeltzer, Bagas Sanjaya, Git Mailing List
Cc: Andrzej Hunt, Ævar Arnfjörð Bjarmason,
Junio C Hamano
Am 27.10.23 um 13:16 schrieb Lior Zeltzer:
> The reproduction ,as I wrote in the code, should be done with few threads in parallel
> Each working on a list of ~10 repos with each repo containing a lot of refs/tags (~1000)
> All this should be against gerrit (my gerrit is 3.8.0)
>
> Also read the notes below regarding the code that was moved between 2.31.8 and 2.32.0 in ls-remote.c file
> I can elaborate more, in a zoom meeting.
>
> 10x
> Lior.
>
>
> -----Original Message-----
> From: Bagas Sanjaya <bagasdotme@gmail.com>
> Sent: Friday, October 27, 2023 4:08 AM
> To: Lior Zeltzer <liorz@marvell.com>; Git Mailing List <git@vger.kernel.org>
> Cc: Andrzej Hunt <ajrhunt@google.com>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>; Junio C Hamano <gitster@pobox.com>
> Subject: [EXT] Re: ls-remote bug
>
> External Email
>
> ----------------------------------------------------------------------
> On Tue, Oct 24, 2023 at 10:55:24AM +0000, Lior Zeltzer wrote:
>>
>>> uname -a
>> Linux dc3lp-veld0045 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16
>> 18:28:22 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Gerrit version :
>> 3.8.0
>>
>> Bug description :
>> When running ls-remote : sometime data gets cut in the middle
>>
>> Reproducing :
>> You need a few files with a few repo names (I used 4 files with 10
>> repos each) Call then l1..l4 And the code below just cd into each of
>> them does ls-remote twice and compares the data Doing it in parallel
>> on all lists.
>> Data received in both ls-remotes should be the same , if not, it
>> prints *** Repos should contain a lot of tags and refs
>
> What repo did you find this regression? Did you mean linux.git (Linux kernel)?
>
>>
>> Note :
>> 1. without stderr redirection (2>&1) all works well 2. On local repos
>> (not through gerrit) all works well
>>
>> I compared various git vers and found the bug to be between 2.31.8 and
>> 2.32.0 Comparing ls-remote.c file between those vers gave me :
>>
>> Lines :
>> if (transport_disconnect(transport))
>> return 1;
>>
>> moved to end of sub
>>
>> copying ls-remote.c from 2.31.8 to 2.32.0 - fixed the bug
This partly undoes 68ffe095a2 (transport: also free remote_refs in
transport_disconnect(), 2021-03-21). With that patch connections are
kept open during ref sorting and printing.
Perhaps the other side gets tired of waiting and aborts? Maybe
splitting transport_disconnect() into two functions -- one for
disconnecting and and for cleaning up -- would make sense? And
disconnecting as soon as possible? Just guessing -- didn't actually
reproduce the bug. Still, demo patch below.
>>
>>
>>
>> Code reproducing bug :
>>
>> #!/proj/mislcad/areas/DAtools/tools/perl/5.10.1/bin/perl -w use
>> strict; use Cwd qw(cwd);
>>
>> my $count = 4;
>> for my $f (1..$count) {
>> my $child = fork();
>> if (!$child) {
>> my $curr = cwd();
>>
>> my @repos = `cat l$f`;
>> foreach my $repo (@repos) {
>> chomp $repo;
>> print "$repo\n";
>> chdir($repo);
>> my $remote_tags_str = `git ls-remote 2>&1`;
>> my $remote_tags_str2 = `git ls-remote 2>&1 `;
>> chdir($curr);
>> if ( $remote_tags_str ne $remote_tags_str2) {
>> print "***\n";
>> }
>> }
>>
>> exit(0);
>> }
>> }
>> while (wait != -1) {}
>> 1;
>>
>
> I tried reproducing this regression by:
>
> ```
> $ cd /path/to/git.git
> $ git ls-remote 2>&1 > /tmp/root.list
> $ cd builtin/
> $ git ls-remote 2>&1 > /tmp/builtin.list $ cd ../ $ git diff --no-index /tmp/root.list /tmp/builtin.list ```
>
> And indeed, the diff was empty (which meant that both listings are same).
>
> Confused...
>
> --
> An old man doll... just what I always wanted! - Clara
---
builtin/ls-remote.c | 8 +++++---
builtin/remote.c | 3 ++-
transport.c | 15 +++++++++++++--
transport.h | 2 ++
4 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index fc76575430..4c1daa0f92 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -128,6 +128,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
int hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
repo_set_hash_algo(the_repository, hash_algo);
}
+ if (transport_disconnect_raw(transport))
+ status = 1;
if (!dest && !quiet)
fprintf(stderr, "From %s\n", *remote->url);
@@ -154,12 +156,12 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
if (show_symref_target && ref->symref)
printf("ref: %s\t%s\n", ref->symref, ref->refname);
printf("%s\t%s\n", oid_to_hex(&ref->objectname), ref->refname);
- status = 0; /* we found something */
+ if (status != 1)
+ status = 0; /* we found something */
}
ref_array_clear(&ref_array);
- if (transport_disconnect(transport))
- status = 1;
+ transport_clear(transport);
transport_ls_refs_options_release(&transport_options);
return status;
}
diff --git a/builtin/remote.c b/builtin/remote.c
index d91bbe728d..055a221942 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1000,6 +1000,7 @@ static int get_remote_ref_states(const char *name,
transport = transport_get(states->remote, states->remote->url_nr > 0 ?
states->remote->url[0] : NULL);
remote_refs = transport_get_remote_refs(transport, NULL);
+ transport_disconnect_raw(transport);
states->queried = 1;
if (query & GET_REF_STATES)
@@ -1008,7 +1009,7 @@ static int get_remote_ref_states(const char *name,
get_head_names(remote_refs, states);
if (query & GET_PUSH_REF_STATES)
get_push_ref_states(remote_refs, states);
- transport_disconnect(transport);
+ transport_clear(transport);
} else {
for_each_ref(append_ref_to_tracked_list, states);
string_list_sort(&states->tracked);
diff --git a/transport.c b/transport.c
index 219af8fd50..c71dab75e9 100644
--- a/transport.c
+++ b/transport.c
@@ -1584,17 +1584,28 @@ int transport_connect(struct transport *transport, const char *name,
die(_("operation not supported by protocol"));
}
-int transport_disconnect(struct transport *transport)
+int transport_disconnect_raw(struct transport *transport)
{
int ret = 0;
if (transport->vtable->disconnect)
ret = transport->vtable->disconnect(transport);
+ return ret;
+}
+
+void transport_clear(struct transport *transport)
+{
if (transport->got_remote_refs)
free_refs((void *)transport->remote_refs);
clear_bundle_list(transport->bundles);
free(transport->bundles);
free(transport);
- return ret;
+}
+
+int transport_disconnect(struct transport *transport)
+{
+ int ret = transport_disconnect_raw(transport);
+ transport_clear(transport);
+ return 0;
}
/*
diff --git a/transport.h b/transport.h
index 6393cd9823..fd75905568 100644
--- a/transport.h
+++ b/transport.h
@@ -320,6 +320,8 @@ int transport_fetch_refs(struct transport *transport, struct ref *refs);
void transport_unlock_pack(struct transport *transport, unsigned int flags);
int transport_disconnect(struct transport *transport);
+void transport_clear(struct transport *transport);
+int transport_disconnect_raw(struct transport *transport);
char *transport_anonymize_url(const char *url);
void transport_take_over(struct transport *transport,
struct child_process *child);
--
2.42.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* RE: [EXT] Re: ls-remote bug
2023-10-29 18:56 ` René Scharfe
@ 2023-10-30 8:17 ` Lior Zeltzer
2023-10-31 10:00 ` René Scharfe
0 siblings, 1 reply; 6+ messages in thread
From: Lior Zeltzer @ 2023-10-30 8:17 UTC (permalink / raw)
To: René Scharfe, Bagas Sanjaya, Git Mailing List
Cc: Andrzej Hunt, Ævar Arnfjörð Bjarmason,
Junio C Hamano
But why when cancelling stderr redirect to stdout (2>&1) all works well ?
-----Original Message-----
From: René Scharfe <l.s.r@web.de>
Sent: Sunday, October 29, 2023 8:57 PM
To: Lior Zeltzer <liorz@marvell.com>; Bagas Sanjaya <bagasdotme@gmail.com>; Git Mailing List <git@vger.kernel.org>
Cc: Andrzej Hunt <ajrhunt@google.com>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>; Junio C Hamano <gitster@pobox.com>
Subject: Re: [EXT] Re: ls-remote bug
Am 27.10.23 um 13:16 schrieb Lior Zeltzer:
> The reproduction ,as I wrote in the code, should be done with few
> threads in parallel Each working on a list of ~10 repos with each repo
> containing a lot of refs/tags (~1000) All this should be against
> gerrit (my gerrit is 3.8.0)
>
> Also read the notes below regarding the code that was moved between
> 2.31.8 and 2.32.0 in ls-remote.c file I can elaborate more, in a zoom meeting.
>
> 10x
> Lior.
>
>
> -----Original Message-----
> From: Bagas Sanjaya <bagasdotme@gmail.com>
> Sent: Friday, October 27, 2023 4:08 AM
> To: Lior Zeltzer <liorz@marvell.com>; Git Mailing List
> <git@vger.kernel.org>
> Cc: Andrzej Hunt <ajrhunt@google.com>; Ævar Arnfjörð Bjarmason
> <avarab@gmail.com>; Junio C Hamano <gitster@pobox.com>
> Subject: [EXT] Re: ls-remote bug
>
> External Email
>
> ----------------------------------------------------------------------
> On Tue, Oct 24, 2023 at 10:55:24AM +0000, Lior Zeltzer wrote:
>>
>>> uname -a
>> Linux dc3lp-veld0045 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16
>> 18:28:22 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Gerrit version :
>> 3.8.0
>>
>> Bug description :
>> When running ls-remote : sometime data gets cut in the middle
>>
>> Reproducing :
>> You need a few files with a few repo names (I used 4 files with 10
>> repos each) Call then l1..l4 And the code below just cd into each of
>> them does ls-remote twice and compares the data Doing it in parallel
>> on all lists.
>> Data received in both ls-remotes should be the same , if not, it
>> prints *** Repos should contain a lot of tags and refs
>
> What repo did you find this regression? Did you mean linux.git (Linux kernel)?
>
>>
>> Note :
>> 1. without stderr redirection (2>&1) all works well 2. On local
>> repos (not through gerrit) all works well
>>
>> I compared various git vers and found the bug to be between 2.31.8
>> and
>> 2.32.0 Comparing ls-remote.c file between those vers gave me :
>>
>> Lines :
>> if (transport_disconnect(transport))
>> return 1;
>>
>> moved to end of sub
>>
>> copying ls-remote.c from 2.31.8 to 2.32.0 - fixed the bug
This partly undoes 68ffe095a2 (transport: also free remote_refs in transport_disconnect(), 2021-03-21). With that patch connections are kept open during ref sorting and printing.
Perhaps the other side gets tired of waiting and aborts? Maybe splitting transport_disconnect() into two functions -- one for disconnecting and and for cleaning up -- would make sense? And disconnecting as soon as possible? Just guessing -- didn't actually reproduce the bug. Still, demo patch below.
>>
>>
>>
>> Code reproducing bug :
>>
>> #!/proj/mislcad/areas/DAtools/tools/perl/5.10.1/bin/perl -w use
>> strict; use Cwd qw(cwd);
>>
>> my $count = 4;
>> for my $f (1..$count) {
>> my $child = fork();
>> if (!$child) {
>> my $curr = cwd();
>>
>> my @repos = `cat l$f`;
>> foreach my $repo (@repos) {
>> chomp $repo;
>> print "$repo\n";
>> chdir($repo);
>> my $remote_tags_str = `git ls-remote 2>&1`;
>> my $remote_tags_str2 = `git ls-remote 2>&1 `;
>> chdir($curr);
>> if ( $remote_tags_str ne $remote_tags_str2) {
>> print "***\n";
>> }
>> }
>>
>> exit(0);
>> }
>> }
>> while (wait != -1) {}
>> 1;
>>
>
> I tried reproducing this regression by:
>
> ```
> $ cd /path/to/git.git
> $ git ls-remote 2>&1 > /tmp/root.list
> $ cd builtin/
> $ git ls-remote 2>&1 > /tmp/builtin.list $ cd ../ $ git diff
> --no-index /tmp/root.list /tmp/builtin.list ```
>
> And indeed, the diff was empty (which meant that both listings are same).
>
> Confused...
>
> --
> An old man doll... just what I always wanted! - Clara
---
builtin/ls-remote.c | 8 +++++---
builtin/remote.c | 3 ++-
transport.c | 15 +++++++++++++--
transport.h | 2 ++
4 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c index fc76575430..4c1daa0f92 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -128,6 +128,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
int hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
repo_set_hash_algo(the_repository, hash_algo);
}
+ if (transport_disconnect_raw(transport))
+ status = 1;
if (!dest && !quiet)
fprintf(stderr, "From %s\n", *remote->url); @@ -154,12 +156,12 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
if (show_symref_target && ref->symref)
printf("ref: %s\t%s\n", ref->symref, ref->refname);
printf("%s\t%s\n", oid_to_hex(&ref->objectname), ref->refname);
- status = 0; /* we found something */
+ if (status != 1)
+ status = 0; /* we found something */
}
ref_array_clear(&ref_array);
- if (transport_disconnect(transport))
- status = 1;
+ transport_clear(transport);
transport_ls_refs_options_release(&transport_options);
return status;
}
diff --git a/builtin/remote.c b/builtin/remote.c index d91bbe728d..055a221942 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1000,6 +1000,7 @@ static int get_remote_ref_states(const char *name,
transport = transport_get(states->remote, states->remote->url_nr > 0 ?
states->remote->url[0] : NULL);
remote_refs = transport_get_remote_refs(transport, NULL);
+ transport_disconnect_raw(transport);
states->queried = 1;
if (query & GET_REF_STATES)
@@ -1008,7 +1009,7 @@ static int get_remote_ref_states(const char *name,
get_head_names(remote_refs, states);
if (query & GET_PUSH_REF_STATES)
get_push_ref_states(remote_refs, states);
- transport_disconnect(transport);
+ transport_clear(transport);
} else {
for_each_ref(append_ref_to_tracked_list, states);
string_list_sort(&states->tracked);
diff --git a/transport.c b/transport.c
index 219af8fd50..c71dab75e9 100644
--- a/transport.c
+++ b/transport.c
@@ -1584,17 +1584,28 @@ int transport_connect(struct transport *transport, const char *name,
die(_("operation not supported by protocol")); }
-int transport_disconnect(struct transport *transport)
+int transport_disconnect_raw(struct transport *transport)
{
int ret = 0;
if (transport->vtable->disconnect)
ret = transport->vtable->disconnect(transport);
+ return ret;
+}
+
+void transport_clear(struct transport *transport) {
if (transport->got_remote_refs)
free_refs((void *)transport->remote_refs);
clear_bundle_list(transport->bundles);
free(transport->bundles);
free(transport);
- return ret;
+}
+
+int transport_disconnect(struct transport *transport) {
+ int ret = transport_disconnect_raw(transport);
+ transport_clear(transport);
+ return 0;
}
/*
diff --git a/transport.h b/transport.h
index 6393cd9823..fd75905568 100644
--- a/transport.h
+++ b/transport.h
@@ -320,6 +320,8 @@ int transport_fetch_refs(struct transport *transport, struct ref *refs);
void transport_unlock_pack(struct transport *transport, unsigned int flags);
int transport_disconnect(struct transport *transport);
+void transport_clear(struct transport *transport);
+int transport_disconnect_raw(struct transport *transport);
char *transport_anonymize_url(const char *url);
void transport_take_over(struct transport *transport,
struct child_process *child);
--
2.42.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [EXT] Re: ls-remote bug
2023-10-30 8:17 ` Lior Zeltzer
@ 2023-10-31 10:00 ` René Scharfe
0 siblings, 0 replies; 6+ messages in thread
From: René Scharfe @ 2023-10-31 10:00 UTC (permalink / raw)
To: Lior Zeltzer, Git Mailing List
Cc: Andrzej Hunt, Ævar Arnfjörð Bjarmason,
Junio C Hamano, Bagas Sanjaya
Am 30.10.23 um 09:17 schrieb Lior Zeltzer:
> But why when cancelling stderr redirect to stdout (2>&1) all works well ?
Good question. Maybe the output on stderr can give a hint? Any error
messages? I assume there is *some* output, otherwise the redirection
should have no effect.
René
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-10-31 10:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <BL0PR18MB2130C672D503E49F955E04E8BADFA@BL0PR18MB2130.namprd18.prod.outlook.com>
2023-10-24 10:55 ` ls-remote bug Lior Zeltzer
2023-10-27 1:08 ` Bagas Sanjaya
2023-10-27 11:16 ` [EXT] " Lior Zeltzer
2023-10-29 18:56 ` René Scharfe
2023-10-30 8:17 ` Lior Zeltzer
2023-10-31 10:00 ` René Scharfe
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).