git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [PATCH] sequencer: fix gpg option passed to octopus merge
@ 2020-10-11 22:48 Samuel Čavoj
  2020-10-11 22:58 ` brian m. carlson
  2020-10-12 19:47 ` Junio C Hamano
  0 siblings, 2 replies; 11+ messages in thread
From: Samuel Čavoj @ 2020-10-11 22:48 UTC (permalink / raw)
  To: git, Junio C Hamano; +Cc: Johannes Schindelin, Jeff King, Samuel Čavoj

When performing octopus merges with interactive rebase with gpgsign
enabled (either using rebase -S or config commit.gpgsign), the operation
would fail on the merge. Instead of "-S%s" with the key id substituted,
only the bare key id would get passed to the underlying merge command,
which tried to interpret it as a ref.

Signed-off-by: Samuel Čavoj <samuel@cavoj.net>
---
It is unclear to me whether I should have based this off of maint or
master, master made more sense to me. I apologize if maint was the
correct one, please tell and I will resubmit.
---
 sequencer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sequencer.c b/sequencer.c
index 00acb12496..88ccff4838 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r,
 		strvec_push(&cmd.args, "-F");
 		strvec_push(&cmd.args, git_path_merge_msg(r));
 		if (opts->gpg_sign)
-			strvec_push(&cmd.args, opts->gpg_sign);
+			strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
 
 		/* Add the tips to be merged */
 		for (j = to_merge; j; j = j->next)
-- 
2.28.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-11 22:48 [PATCH] sequencer: fix gpg option passed to octopus merge Samuel Čavoj
@ 2020-10-11 22:58 ` brian m. carlson
  2020-10-12 10:34   ` Johannes Schindelin
  2020-10-12 19:47 ` Junio C Hamano
  1 sibling, 1 reply; 11+ messages in thread
From: brian m. carlson @ 2020-10-11 22:58 UTC (permalink / raw)
  To: Samuel Čavoj; +Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

On 2020-10-11 at 22:48:04, Samuel Čavoj wrote:
> When performing octopus merges with interactive rebase with gpgsign
> enabled (either using rebase -S or config commit.gpgsign), the operation
> would fail on the merge. Instead of "-S%s" with the key id substituted,
> only the bare key id would get passed to the underlying merge command,
> which tried to interpret it as a ref.
> 
> Signed-off-by: Samuel Čavoj <samuel@cavoj.net>
> ---
> It is unclear to me whether I should have based this off of maint or
> master, master made more sense to me. I apologize if maint was the
> correct one, please tell and I will resubmit.
> ---
>  sequencer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sequencer.c b/sequencer.c
> index 00acb12496..88ccff4838 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r,
>  		strvec_push(&cmd.args, "-F");
>  		strvec_push(&cmd.args, git_path_merge_msg(r));
>  		if (opts->gpg_sign)
> -			strvec_push(&cmd.args, opts->gpg_sign);
> +			strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);

Yeah, this seems obviously correct, and it's very similar to what we do
elsewhere in the file.  This will also handle the case where the option
is empty (because we want to do autodetection of the key to sign)
correctly as well.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-11 22:58 ` brian m. carlson
@ 2020-10-12 10:34   ` Johannes Schindelin
  2020-10-12 13:15     ` Phillip Wood
  0 siblings, 1 reply; 11+ messages in thread
From: Johannes Schindelin @ 2020-10-12 10:34 UTC (permalink / raw)
  To: brian m. carlson; +Cc: Samuel Čavoj, git, Junio C Hamano, Jeff King

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

Hi,

On Sun, 11 Oct 2020, brian m. carlson wrote:

> On 2020-10-11 at 22:48:04, Samuel Čavoj wrote:
> > When performing octopus merges with interactive rebase with gpgsign
> > enabled (either using rebase -S or config commit.gpgsign), the operation
> > would fail on the merge. Instead of "-S%s" with the key id substituted,
> > only the bare key id would get passed to the underlying merge command,
> > which tried to interpret it as a ref.
> >
> > Signed-off-by: Samuel Čavoj <samuel@cavoj.net>
> > ---
> > It is unclear to me whether I should have based this off of maint or
> > master, master made more sense to me. I apologize if maint was the
> > correct one, please tell and I will resubmit.
> > ---
> >  sequencer.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sequencer.c b/sequencer.c
> > index 00acb12496..88ccff4838 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r,
> >  		strvec_push(&cmd.args, "-F");
> >  		strvec_push(&cmd.args, git_path_merge_msg(r));
> >  		if (opts->gpg_sign)
> > -			strvec_push(&cmd.args, opts->gpg_sign);
> > +			strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
>
> Yeah, this seems obviously correct, and it's very similar to what we do
> elsewhere in the file.  This will also handle the case where the option
> is empty (because we want to do autodetection of the key to sign)
> correctly as well.

ACK

It is unclear to me whether we want to bother introducing a test case for
this; Octopus merges are somewhat rare...

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-12 10:34   ` Johannes Schindelin
@ 2020-10-12 13:15     ` Phillip Wood
  2020-10-12 16:56       ` Junio C Hamano
  0 siblings, 1 reply; 11+ messages in thread
From: Phillip Wood @ 2020-10-12 13:15 UTC (permalink / raw)
  To: Johannes Schindelin, brian m. carlson
  Cc: Samuel Čavoj, git, Junio C Hamano, Jeff King

Thanks for the patch Samuel

On 12/10/2020 11:34, Johannes Schindelin wrote:
> Hi,
> 
> On Sun, 11 Oct 2020, brian m. carlson wrote:
> 
>> On 2020-10-11 at 22:48:04, Samuel Čavoj wrote:
>>> When performing octopus merges with interactive rebase with gpgsign
>>> enabled (either using rebase -S or config commit.gpgsign), the operation
>>> would fail on the merge. Instead of "-S%s" with the key id substituted,
>>> only the bare key id would get passed to the underlying merge command,
>>> which tried to interpret it as a ref.
>>>
>>> Signed-off-by: Samuel Čavoj <samuel@cavoj.net>
>>> ---
>>> It is unclear to me whether I should have based this off of maint or
>>> master, master made more sense to me. I apologize if maint was the
>>> correct one, please tell and I will resubmit.
>>> ---
>>>   sequencer.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/sequencer.c b/sequencer.c
>>> index 00acb12496..88ccff4838 100644
>>> --- a/sequencer.c
>>> +++ b/sequencer.c
>>> @@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r,
>>>   		strvec_push(&cmd.args, "-F");
>>>   		strvec_push(&cmd.args, git_path_merge_msg(r));
>>>   		if (opts->gpg_sign)
>>> -			strvec_push(&cmd.args, opts->gpg_sign);
>>> +			strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
>>
>> Yeah, this seems obviously correct, and it's very similar to what we do
>> elsewhere in the file.
In run_git_commit() we do

	if (opts->gpg_sign)
		strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
	else
		strvec_push(&cmd.args, "--no-gpg-sign");

I'm not immediately clear why we pass --no-gpg-sign when opts->gpg_sign 
isn't set but it makes me wonder if we should be doing that here as well

>  This will also handle the case where the option
>> is empty (because we want to do autodetection of the key to sign)
>> correctly as well.
> 
> ACK
> 
> It is unclear to me whether we want to bother introducing a test case for
> this; Octopus merges are somewhat rare...

This code path is used whenever the user specifies a merge strategy 
other than "recursive" or they pass merge strategy options to any merge 
strategy including "recursive" so while octopus merges may be rare the 
union of everything other than a plain recursive merge may not be.

Best Wishes

Phillip

> 
> Ciao,
> Dscho
> 


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-12 13:15     ` Phillip Wood
@ 2020-10-12 16:56       ` Junio C Hamano
  2020-10-12 19:26         ` Phillip Wood
  2020-10-12 19:41         ` Junio C Hamano
  0 siblings, 2 replies; 11+ messages in thread
From: Junio C Hamano @ 2020-10-12 16:56 UTC (permalink / raw)
  To: Phillip Wood
  Cc: Johannes Schindelin, brian m. carlson, Samuel Čavoj, git, Jeff King

Phillip Wood <phillip.wood123@gmail.com> writes:

> In run_git_commit() we do
>
> 	if (opts->gpg_sign)
> 		strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
> 	else
> 		strvec_push(&cmd.args, "--no-gpg-sign");
>
> I'm not immediately clear why we pass --no-gpg-sign when
> opts->gpg_sign isn't set ...

Isn't it because there is a configuration that the &cmd may honor
that forces gpg signing all the time?

> but it makes me wonder if we should be doing
> that here as well

Possibly.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-12 16:56       ` Junio C Hamano
@ 2020-10-12 19:26         ` Phillip Wood
  2020-10-12 19:41         ` Junio C Hamano
  1 sibling, 0 replies; 11+ messages in thread
From: Phillip Wood @ 2020-10-12 19:26 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Johannes Schindelin, brian m. carlson, Samuel Čavoj, git, Jeff King

On 12/10/2020 17:56, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> In run_git_commit() we do
>>
>> 	if (opts->gpg_sign)
>> 		strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
>> 	else
>> 		strvec_push(&cmd.args, "--no-gpg-sign");
>>
>> I'm not immediately clear why we pass --no-gpg-sign when
>> opts->gpg_sign isn't set ...
> 
> Isn't it because there is a configuration that the &cmd may honor
> that forces gpg signing all the time?

Yes you're right, so we should be passing --no-gpg-sign here if 
opts->gpg_sign == NULL, otherwise `git merge` will still sign commits 
when it is run by `git rebase --no-gpg-sign`

Best Wishes

Phillip

> 
>> but it makes me wonder if we should be doing
>> that here as well
> 
> Possibly.
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-12 16:56       ` Junio C Hamano
  2020-10-12 19:26         ` Phillip Wood
@ 2020-10-12 19:41         ` Junio C Hamano
  2020-10-12 20:11           ` Junio C Hamano
  1 sibling, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2020-10-12 19:41 UTC (permalink / raw)
  To: Phillip Wood
  Cc: Johannes Schindelin, brian m. carlson, Samuel Čavoj, git, Jeff King

Junio C Hamano <gitster@pobox.com> writes:

> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>> In run_git_commit() we do
>>
>> 	if (opts->gpg_sign)
>> 		strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
>> 	else
>> 		strvec_push(&cmd.args, "--no-gpg-sign");
>>
>> I'm not immediately clear why we pass --no-gpg-sign when
>> opts->gpg_sign isn't set ...
>
> Isn't it because there is a configuration that the &cmd may honor
> that forces gpg signing all the time?
>
>> but it makes me wonder if we should be doing
>> that here as well

I was reacting only based on what I saw in these message, but it
turns out that cmd above is an internal invocation of "git merge";
as the command does honor the "commit.gpgsign" option, if "rebase"
or whatever command that invoked the sequencer turned off the
signing by setting opts->gpg_sign to false, I agree that the part
touched by the patch should have the else clause to explicitly
override the configuration option.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-11 22:48 [PATCH] sequencer: fix gpg option passed to octopus merge Samuel Čavoj
  2020-10-11 22:58 ` brian m. carlson
@ 2020-10-12 19:47 ` Junio C Hamano
  2020-10-12 20:55   ` Johannes Schindelin
  1 sibling, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2020-10-12 19:47 UTC (permalink / raw)
  To: Samuel Čavoj; +Cc: git, Johannes Schindelin, Jeff King

Samuel Čavoj <samuel@cavoj.net> writes:

> Subject: Re: [PATCH] sequencer: fix gpg option passed to octopus merge

Puzzling.  Why do you single out octopus merge like this?

sequencer.c::do_merge() is called from pick_commits() whenever we
see a "merge" insn, and not limited to an octopus merge.

Can we have a test to demonstrate the existing failure, so that we
can notice if this fix is broken in the future?

> When performing octopus merges with interactive rebase with gpgsign
> enabled (either using rebase -S or config commit.gpgsign), the operation
> would fail on the merge. Instead of "-S%s" with the key id substituted,
> only the bare key id would get passed to the underlying merge command,
> which tried to interpret it as a ref.
>
> Signed-off-by: Samuel Čavoj <samuel@cavoj.net>
> ---
> It is unclear to me whether I should have based this off of maint or
> master, master made more sense to me. I apologize if maint was the
> correct one, please tell and I will resubmit.
> ---
>  sequencer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 00acb12496..88ccff4838 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r,
>  		strvec_push(&cmd.args, "-F");
>  		strvec_push(&cmd.args, git_path_merge_msg(r));
>  		if (opts->gpg_sign)
> -			strvec_push(&cmd.args, opts->gpg_sign);
> +			strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
>  
>  		/* Add the tips to be merged */
>  		for (j = to_merge; j; j = j->next)

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-12 19:41         ` Junio C Hamano
@ 2020-10-12 20:11           ` Junio C Hamano
  0 siblings, 0 replies; 11+ messages in thread
From: Junio C Hamano @ 2020-10-12 20:11 UTC (permalink / raw)
  To: Phillip Wood
  Cc: Johannes Schindelin, brian m. carlson, Samuel Čavoj, git, Jeff King

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>>
>>> In run_git_commit() we do
>>>
>>> 	if (opts->gpg_sign)
>>> 		strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
>>> 	else
>>> 		strvec_push(&cmd.args, "--no-gpg-sign");
>>>
>>> I'm not immediately clear why we pass --no-gpg-sign when
>>> opts->gpg_sign isn't set ...
>>
>> Isn't it because there is a configuration that the &cmd may honor
>> that forces gpg signing all the time?
>>
>>> but it makes me wonder if we should be doing
>>> that here as well
>
> I was reacting only based on what I saw in these message, but it
> turns out that cmd above is an internal invocation of "git merge";
> as the command does honor the "commit.gpgsign" option, if "rebase"
> or whatever command that invoked the sequencer turned off the
> signing by setting opts->gpg_sign to false, I agree that the part
> touched by the patch should have the else clause to explicitly
> override the configuration option.

Forgot to say that it is perfectly fine to leave it outside Samuel's
patch.  It "fixes" the "intended" behaviour of the current design
where it somehow was deemed a good idea to disallow overriding
commit.gpgsign variable.  Fixing that design so that we can override
configured default from the command line can be left for a follow-up
patch.

Thanks.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-12 19:47 ` Junio C Hamano
@ 2020-10-12 20:55   ` Johannes Schindelin
  2020-10-13  4:45     ` Junio C Hamano
  0 siblings, 1 reply; 11+ messages in thread
From: Johannes Schindelin @ 2020-10-12 20:55 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Samuel Čavoj, git, Jeff King

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

Hi,

On Mon, 12 Oct 2020, Junio C Hamano wrote:

> Samuel Čavoj <samuel@cavoj.net> writes:
>
> > Subject: Re: [PATCH] sequencer: fix gpg option passed to octopus merge
>
> Puzzling.  Why do you single out octopus merge like this?
>
> sequencer.c::do_merge() is called from pick_commits() whenever we
> see a "merge" insn, and not limited to an octopus merge.
>
> Can we have a test to demonstrate the existing failure, so that we
> can notice if this fix is broken in the future?

Yes, now that I understand that not only octopus merges are affected, I
would be very much in favor of adding a test case.

If I may suggest to add a new test case to t3435 based on t3430's
'--rebase-merges with strategies' and t3404's 'rebase -i
--gpg-sign=<key-id>'? Something along these lines:

-- snipsnap --
diff --git a/sequencer.c b/sequencer.c
index 00acb124962..88ccff4838d 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r,
 		strvec_push(&cmd.args, "-F");
 		strvec_push(&cmd.args, git_path_merge_msg(r));
 		if (opts->gpg_sign)
-			strvec_push(&cmd.args, opts->gpg_sign);
+			strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);

 		/* Add the tips to be merged */
 		for (j = to_merge; j; j = j->next)
diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh
index b47c59c190b..f70b280f5c1 100755
--- a/t/t3435-rebase-gpg-sign.sh
+++ b/t/t3435-rebase-gpg-sign.sh
@@ -68,4 +68,10 @@ test_expect_failure 'rebase -p --no-gpg-sign override commit.gpgsign' '
 	test_must_fail git verify-commit HEAD
 '

+test_expect_success 'rebase -r, GPG and merge strategies' '
+	git reset --hard merged &&
+	git rebase -fr --gpg-sign -s resolve --root &&
+	git verify-commit HEAD
+'
+
 test_done

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] sequencer: fix gpg option passed to octopus merge
  2020-10-12 20:55   ` Johannes Schindelin
@ 2020-10-13  4:45     ` Junio C Hamano
  0 siblings, 0 replies; 11+ messages in thread
From: Junio C Hamano @ 2020-10-13  4:45 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Samuel Čavoj, git, Jeff King

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> Puzzling.  Why do you single out octopus merge like this?
>>
>> sequencer.c::do_merge() is called from pick_commits() whenever we
>> see a "merge" insn, and not limited to an octopus merge.
>>
>> Can we have a test to demonstrate the existing failure, so that we
>> can notice if this fix is broken in the future?
>
> Yes, now that I understand that not only octopus merges are affected, I
> would be very much in favor of adding a test case.

Ah, I see why the initial description was focused on octopus.  The
code special cases the two-parent merge using the recursive strategy
and uses completely separate codepath for it, which does not have
this problem but the codepath that handles octopus merges and merges
with the non-default strategy have the problem.

> If I may suggest to add a new test case to t3435 based on t3430's
> '--rebase-merges with strategies' and t3404's 'rebase -i
> --gpg-sign=<key-id>'? Something along these lines:

In addition, a test that passes --no-gpg-sign from the command line, 
because commit.gpgsign is set in the repository used in these tests,
would be necessary---we want to make sure the command line overrides
the configured default (which is the topic of [patch 2/1]).

>
> -- snipsnap --
> diff --git a/sequencer.c b/sequencer.c
> index 00acb124962..88ccff4838d 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r,
>  		strvec_push(&cmd.args, "-F");
>  		strvec_push(&cmd.args, git_path_merge_msg(r));
>  		if (opts->gpg_sign)
> -			strvec_push(&cmd.args, opts->gpg_sign);
> +			strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
>
>  		/* Add the tips to be merged */
>  		for (j = to_merge; j; j = j->next)
> diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh
> index b47c59c190b..f70b280f5c1 100755
> --- a/t/t3435-rebase-gpg-sign.sh
> +++ b/t/t3435-rebase-gpg-sign.sh
> @@ -68,4 +68,10 @@ test_expect_failure 'rebase -p --no-gpg-sign override commit.gpgsign' '
>  	test_must_fail git verify-commit HEAD
>  '
>
> +test_expect_success 'rebase -r, GPG and merge strategies' '
> +	git reset --hard merged &&
> +	git rebase -fr --gpg-sign -s resolve --root &&
> +	git verify-commit HEAD
> +'
> +
>  test_done

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-10-13  4:45 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-11 22:48 [PATCH] sequencer: fix gpg option passed to octopus merge Samuel Čavoj
2020-10-11 22:58 ` brian m. carlson
2020-10-12 10:34   ` Johannes Schindelin
2020-10-12 13:15     ` Phillip Wood
2020-10-12 16:56       ` Junio C Hamano
2020-10-12 19:26         ` Phillip Wood
2020-10-12 19:41         ` Junio C Hamano
2020-10-12 20:11           ` Junio C Hamano
2020-10-12 19:47 ` Junio C Hamano
2020-10-12 20:55   ` Johannes Schindelin
2020-10-13  4:45     ` Junio C Hamano

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git