git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* [PATCH] sha1-name.c: for ":/", find detached HEAD commits
@ 2018-07-10 15:41 William Chargin
  2018-07-10 17:54 ` Jeff King
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: William Chargin @ 2018-07-10 15:41 UTC (permalink / raw)
  To: git; +Cc: William Chargin, Jeff King

This patch broadens the set of commits matched by ":/" pathspecs to
include commits reachable from HEAD but not any named ref. This avoids
surprising behavior when working with a detached HEAD and trying to
refer to a commit that was recently created and only exists within the
detached state.

Signed-off-by: William Chargin <wchargin@gmail.com>
Based-on-patch-by: Jeff King <peff@peff.net>
---
 Documentation/revisions.txt   | 10 +++++-----
 sha1-name.c                   |  1 +
 t/t4208-log-magic-pathspec.sh | 14 ++++++++++++++
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 7d1bd4409..aa56907fd 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -181,11 +181,11 @@ existing tag object.
   the '<rev>' before '{caret}'.
 
 ':/<text>', e.g. ':/fix nasty bug'::
-  A colon, followed by a slash, followed by a text, names
-  a commit whose commit message matches the specified regular expression.
-  This name returns the youngest matching commit which is
-  reachable from any ref. The regular expression can match any part of the
-  commit message. To match messages starting with a string, one can use
+  A colon, followed by a slash, followed by a text, names a commit whose
+  commit message matches the specified regular expression. This name
+  returns the youngest matching commit which is reachable from any ref
+  or from HEAD. The regular expression can match any part of the commit
+  message. To match messages starting with a string, one can use
   e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
   is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a
   literal '!' character, followed by 'foo'. Any other sequence beginning with
diff --git a/sha1-name.c b/sha1-name.c
index 60d9ef3c7..641ca12f9 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
 			struct commit_list *list = NULL;
 
 			for_each_ref(handle_one_ref, &list);
+			head_ref(handle_one_ref, &list);
 			commit_list_sort_by_date(&list);
 			return get_oid_oneline(name + 2, oid, list);
 		}
diff --git a/t/t4208-log-magic-pathspec.sh b/t/t4208-log-magic-pathspec.sh
index 62f335b2d..41b9f3eba 100755
--- a/t/t4208-log-magic-pathspec.sh
+++ b/t/t4208-log-magic-pathspec.sh
@@ -25,6 +25,20 @@ test_expect_success '"git log :/a -- " should not be ambiguous' '
 	git log :/a --
 '
 
+test_expect_success '"git log :/detached -- " should find a commit only in HEAD' '
+	test_when_finished "git checkout master" &&
+	git checkout --detach &&
+	test_tick &&
+	git commit --allow-empty -m detached &&
+	test_tick &&
+	git commit --allow-empty -m something-else &&
+	git log :/detached --
+'
+
+test_expect_success '"git log :/detached -- " should not find an orphaned commit' '
+	test_must_fail git log :/detached --
+'
+
 test_expect_success '"git log -- :/a" should not be ambiguous' '
 	git log -- :/a
 '
-- 
2.18.0.130.g61d0c9dcf


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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-10 15:41 [PATCH] sha1-name.c: for ":/", find detached HEAD commits William Chargin
@ 2018-07-10 17:54 ` Jeff King
  2018-07-10 19:06 ` Junio C Hamano
  2018-07-11 15:45 ` Duy Nguyen
  2 siblings, 0 replies; 19+ messages in thread
From: Jeff King @ 2018-07-10 17:54 UTC (permalink / raw)
  To: William Chargin; +Cc: git

On Tue, Jul 10, 2018 at 08:41:06AM -0700, William Chargin wrote:

> This patch broadens the set of commits matched by ":/" pathspecs to
> include commits reachable from HEAD but not any named ref. This avoids
> surprising behavior when working with a detached HEAD and trying to
> refer to a commit that was recently created and only exists within the
> detached state.
> 
> Signed-off-by: William Chargin <wchargin@gmail.com>
> Based-on-patch-by: Jeff King <peff@peff.net>

Thanks, this looks perfect!

Just to be clear on licensing, I'll add my:

  Signed-off-by: Jeff King <peff@peff.net>

> diff --git a/t/t4208-log-magic-pathspec.sh b/t/t4208-log-magic-pathspec.sh
> index 62f335b2d..41b9f3eba 100755
> --- a/t/t4208-log-magic-pathspec.sh
> +++ b/t/t4208-log-magic-pathspec.sh
> @@ -25,6 +25,20 @@ test_expect_success '"git log :/a -- " should not be ambiguous' '
>  	git log :/a --
>  '
>  
> +test_expect_success '"git log :/detached -- " should find a commit only in HEAD' '
> +	test_when_finished "git checkout master" &&
> +	git checkout --detach &&
> +	test_tick &&
> +	git commit --allow-empty -m detached &&
> +	test_tick &&
> +	git commit --allow-empty -m something-else &&
> +	git log :/detached --
> +'

At first I wondered if you could just use test_commit here (instead of a
manual test_tick and commit). But we care about reachability only from
the detached HEAD here, so this must _not_ use test_commit, which
creates an extra tag.

It could be worth mentioning that in a comment (since somebody who later
refactors to make that change would not realize the problem, as it would
simply cause a broken test to return a false success). But...

> +test_expect_success '"git log :/detached -- " should not find an orphaned commit' '
> +	test_must_fail git log :/detached --
> +'

This follow-up test _would_ notice such a breakage. Very nicely done.

-Peff

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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-10 15:41 [PATCH] sha1-name.c: for ":/", find detached HEAD commits William Chargin
  2018-07-10 17:54 ` Jeff King
@ 2018-07-10 19:06 ` Junio C Hamano
  2018-07-11  6:18   ` William Chargin
  2018-07-11 15:45 ` Duy Nguyen
  2 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2018-07-10 19:06 UTC (permalink / raw)
  To: William Chargin; +Cc: git, Jeff King

William Chargin <wchargin@gmail.com> writes:

> This patch broadens the set of commits matched by ":/" pathspecs to
> include commits reachable from HEAD but not any named ref. This avoids
> surprising behavior when working with a detached HEAD and trying to
> refer to a commit that was recently created and only exists within the
> detached state.
>
> Signed-off-by: William Chargin <wchargin@gmail.com>
> Based-on-patch-by: Jeff King <peff@peff.net>
> ---
>  Documentation/revisions.txt   | 10 +++++-----
>  sha1-name.c                   |  1 +
>  t/t4208-log-magic-pathspec.sh | 14 ++++++++++++++
>  3 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> index 7d1bd4409..aa56907fd 100644
> --- a/Documentation/revisions.txt
> +++ b/Documentation/revisions.txt
> @@ -181,11 +181,11 @@ existing tag object.
>    the '<rev>' before '{caret}'.
>  
>  ':/<text>', e.g. ':/fix nasty bug'::
> -  A colon, followed by a slash, followed by a text, names
> -  a commit whose commit message matches the specified regular expression.
> -  This name returns the youngest matching commit which is
> -  reachable from any ref. The regular expression can match any part of the
> -  commit message. To match messages starting with a string, one can use
> +  A colon, followed by a slash, followed by a text, names a commit whose
> +  commit message matches the specified regular expression. This name
> +  returns the youngest matching commit which is reachable from any ref
> +  or from HEAD. The regular expression can match any part of the commit
> +  message. To match messages starting with a string, one can use

Please avoid unnecessary reflowing of earlier lines of the paragrpah
when the only change is to insert "or from HEAD" in the middle of its
fourth line.  That wastes reviewers time (and typically there are
more readers than there are writers).  If you did this instead:

  A colon, followed by a slash, followed by a text, names
  a commit whose commit message matches the specified regular expression.
  This name returns the youngest matching commit which is
  reachable from any ref or from HEAD.
  The regular expression can match any part of the
  commit message. To match messages starting with a string, one can use

the resulting patch would have been much easier to follow.

Also, I am not sure if "or from HEAD" is even needed when we say
"from ANY ref" already, as we count things like HEAD as part of the
ref namespace.  It may only feel necessary for the person who made
the change to call handle_one_ref() not only with for_each_ref() but
also with head_ref()---in other words, I am wondering if it was
merely a bug to ignore HEAD in the code when the documentation said
"from any ref" already.  If that is the case, then the above change
is not necessary.

> diff --git a/sha1-name.c b/sha1-name.c
> index 60d9ef3c7..641ca12f9 100644
> --- a/sha1-name.c
> +++ b/sha1-name.c
> @@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
>  			struct commit_list *list = NULL;
>  
>  			for_each_ref(handle_one_ref, &list);
> +			head_ref(handle_one_ref, &list);

Makes sense.

>  			commit_list_sort_by_date(&list);
>  			return get_oid_oneline(name + 2, oid, list);
>  		}
> diff --git a/t/t4208-log-magic-pathspec.sh b/t/t4208-log-magic-pathspec.sh
> index 62f335b2d..41b9f3eba 100755
> --- a/t/t4208-log-magic-pathspec.sh
> +++ b/t/t4208-log-magic-pathspec.sh
> @@ -25,6 +25,20 @@ test_expect_success '"git log :/a -- " should not be ambiguous' '
>  	git log :/a --
>  '
>  
> +test_expect_success '"git log :/detached -- " should find a commit only in HEAD' '
> +	test_when_finished "git checkout master" &&
> +	git checkout --detach &&
> +	test_tick &&
> +	git commit --allow-empty -m detached &&
> +	test_tick &&
> +	git commit --allow-empty -m something-else &&
> +	git log :/detached --
> +'
> +
> +test_expect_success '"git log :/detached -- " should not find an orphaned commit' '
> +	test_must_fail git log :/detached --
> +'
> +

OK.

I found these tests (including the existing ones) misleading, by the
way. We are interested in seeing that ":/string" is understood as a
valid object name, and this is not limited to "log" at all.  Instead
of "git log", perhaps "git rev-parse --verify :/detached" may have
been more to the point of what we are actually trying to see.

But that is a fault of having test for ":/<string>" in "magic pathspec"
test script; correcting that mistake is totally outside of the scope
of this fix.

Thanks.

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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-10 19:06 ` Junio C Hamano
@ 2018-07-11  6:18   ` William Chargin
  2018-07-11 12:32     ` Jeff King
  0 siblings, 1 reply; 19+ messages in thread
From: William Chargin @ 2018-07-11  6:18 UTC (permalink / raw)
  To: Junio C Hamano, Jeff King; +Cc: git

> we care about reachability only from the detached HEAD here, so this
> must _not_ use test_commit, which creates an extra tag.

Right. I can add a comment to that effect.

> Please avoid unnecessary reflowing of earlier lines of the paragrpah
> when the only change is to insert "or from HEAD" in the middle of its
> fourth line.

Sure: I'll make that change. (My intent was to incrementally clean up an
area already under change, but I'm happy to instead make only the
minimal change.)

> Also, I am not sure if "or from HEAD" is even needed when we say
> "from ANY ref" already, as we count things like HEAD as part of the
> ref namespace.

My two cents: with the docs as is, I wasn't sure whether HEAD was
intended to count as a ref for this purpose. The gitglossary man page
defines a ref as a "name that begins with refs/" (seemingly excluding
HEAD), though it later says that HEAD is a "special-purpose ref". In my
opinion, the change adds clarity without any particular downside---but
I'm happy to revert it if you'd prefer. I'd also be happy to change the
wording to something like "any ref, including HEAD" if we want to
emphasize that HEAD really is a ref.

> We are interested in seeing that ":/string" is understood as a valid
> object name, and this is not limited to "log" at all.

Indeed. I was a bit surprised for the same reason (I expected the tests
to be using `rev-parse`), but I agree that it's probably best to keep
the existing structure to minimize churn.

---

After reaching consensus on the change to the docs, should I send in a
[PATCH v2] In-Reply-To this thread? Peff, should I add your
Signed-off-by to the commit message, or is that not how things are done?

Best,
WC

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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-11  6:18   ` William Chargin
@ 2018-07-11 12:32     ` Jeff King
  2018-07-11 16:34       ` Junio C Hamano
  0 siblings, 1 reply; 19+ messages in thread
From: Jeff King @ 2018-07-11 12:32 UTC (permalink / raw)
  To: William Chargin; +Cc: Junio C Hamano, git

On Tue, Jul 10, 2018 at 11:18:22PM -0700, William Chargin wrote:

> > Also, I am not sure if "or from HEAD" is even needed when we say
> > "from ANY ref" already, as we count things like HEAD as part of the
> > ref namespace.
> 
> My two cents: with the docs as is, I wasn't sure whether HEAD was
> intended to count as a ref for this purpose. The gitglossary man page
> defines a ref as a "name that begins with refs/" (seemingly excluding
> HEAD), though it later says that HEAD is a "special-purpose ref". In my
> opinion, the change adds clarity without any particular downside---but
> I'm happy to revert it if you'd prefer. I'd also be happy to change the
> wording to something like "any ref, including HEAD" if we want to
> emphasize that HEAD really is a ref.

FWIW, I think the clarification to include HEAD is helpful here, since
it took me a few minutes of thinking to decide whether the current
behavior was a bug or just a subtlety. Your "including HEAD" suggestion
seems like the best route to me. But I can live with it either way.

> After reaching consensus on the change to the docs, should I send in a
> [PATCH v2] In-Reply-To this thread?

Yes.

> Peff, should I add your
> Signed-off-by to the commit message, or is that not how things are done?

Yes, you can add in any sign-offs that have been explicitly given. It's
normal to order them chronologically, too (so mine would come first,
then yours, showing that the patch flowed through me to you; Junio will
add his at the end).

-Peff

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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-10 15:41 [PATCH] sha1-name.c: for ":/", find detached HEAD commits William Chargin
  2018-07-10 17:54 ` Jeff King
  2018-07-10 19:06 ` Junio C Hamano
@ 2018-07-11 15:45 ` Duy Nguyen
  2018-07-11 16:40   ` Jeff King
  2018-07-11 17:20   ` Junio C Hamano
  2 siblings, 2 replies; 19+ messages in thread
From: Duy Nguyen @ 2018-07-11 15:45 UTC (permalink / raw)
  To: wchargin; +Cc: Git Mailing List, Jeff King

On Tue, Jul 10, 2018 at 5:44 PM William Chargin <wchargin@gmail.com> wrote:
>
> This patch broadens the set of commits matched by ":/" pathspecs to
> include commits reachable from HEAD but not any named ref. This avoids
> surprising behavior when working with a detached HEAD and trying to
> refer to a commit that was recently created and only exists within the
> detached state.

Cool!

>
> Signed-off-by: William Chargin <wchargin@gmail.com>
> Based-on-patch-by: Jeff King <peff@peff.net>
> ---
>  Documentation/revisions.txt   | 10 +++++-----
>  sha1-name.c                   |  1 +
>  t/t4208-log-magic-pathspec.sh | 14 ++++++++++++++
>  3 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> index 7d1bd4409..aa56907fd 100644
> --- a/Documentation/revisions.txt
> +++ b/Documentation/revisions.txt
> @@ -181,11 +181,11 @@ existing tag object.
>    the '<rev>' before '{caret}'.
>
>  ':/<text>', e.g. ':/fix nasty bug'::
> -  A colon, followed by a slash, followed by a text, names
> -  a commit whose commit message matches the specified regular expression.
> -  This name returns the youngest matching commit which is
> -  reachable from any ref. The regular expression can match any part of the
> -  commit message. To match messages starting with a string, one can use
> +  A colon, followed by a slash, followed by a text, names a commit whose
> +  commit message matches the specified regular expression. This name
> +  returns the youngest matching commit which is reachable from any ref
> +  or from HEAD. The regular expression can match any part of the commit
> +  message. To match messages starting with a string, one can use
>    e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
>    is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a
>    literal '!' character, followed by 'foo'. Any other sequence beginning with
> diff --git a/sha1-name.c b/sha1-name.c
> index 60d9ef3c7..641ca12f9 100644
> --- a/sha1-name.c
> +++ b/sha1-name.c
> @@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
>                         struct commit_list *list = NULL;
>
>                         for_each_ref(handle_one_ref, &list);
> +                       head_ref(handle_one_ref, &list);

When multiple worktrees are used, should we consider all HEADs or just
current worktree's HEAD?

This is the latter case, if we should go with the former (I don't
know, it's a genuine question) then you need one more call:
other_head_refs().

>                         commit_list_sort_by_date(&list);
>                         return get_oid_oneline(name + 2, oid, list);
>                 }
> diff --git a/t/t4208-log-magic-pathspec.sh b/t/t4208-log-magic-pathspec.sh
> index 62f335b2d..41b9f3eba 100755
> --- a/t/t4208-log-magic-pathspec.sh
> +++ b/t/t4208-log-magic-pathspec.sh
> @@ -25,6 +25,20 @@ test_expect_success '"git log :/a -- " should not be ambiguous' '
>         git log :/a --
>  '
>
> +test_expect_success '"git log :/detached -- " should find a commit only in HEAD' '
> +       test_when_finished "git checkout master" &&
> +       git checkout --detach &&
> +       test_tick &&
> +       git commit --allow-empty -m detached &&
> +       test_tick &&
> +       git commit --allow-empty -m something-else &&
> +       git log :/detached --
> +'
> +
> +test_expect_success '"git log :/detached -- " should not find an orphaned commit' '
> +       test_must_fail git log :/detached --
> +'
> +
>  test_expect_success '"git log -- :/a" should not be ambiguous' '
>         git log -- :/a
>  '
> --
> 2.18.0.130.g61d0c9dcf
>


-- 
Duy

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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-11 12:32     ` Jeff King
@ 2018-07-11 16:34       ` Junio C Hamano
  0 siblings, 0 replies; 19+ messages in thread
From: Junio C Hamano @ 2018-07-11 16:34 UTC (permalink / raw)
  To: Jeff King; +Cc: William Chargin, git

Jeff King <peff@peff.net> writes:

> On Tue, Jul 10, 2018 at 11:18:22PM -0700, William Chargin wrote:
>
>> > Also, I am not sure if "or from HEAD" is even needed when we say
>> > "from ANY ref" already, as we count things like HEAD as part of the
>> > ref namespace.
>> 
>> My two cents: with the docs as is, I wasn't sure whether HEAD was
>> intended to count as a ref for this purpose. The gitglossary man page
>> defines a ref as a "name that begins with refs/" (seemingly excluding
>> HEAD), though it later says that HEAD is a "special-purpose ref". In my
>> opinion, the change adds clarity without any particular downside---but
>> I'm happy to revert it if you'd prefer. I'd also be happy to change the
>> wording to something like "any ref, including HEAD" if we want to
>> emphasize that HEAD really is a ref.
>
> FWIW, I think the clarification to include HEAD is helpful here, since
> it took me a few minutes of thinking to decide whether the current
> behavior was a bug or just a subtlety. Your "including HEAD" suggestion
> seems like the best route to me. But I can live with it either way.
>
>> After reaching consensus on the change to the docs, should I send in a
>> [PATCH v2] In-Reply-To this thread?
>
> Yes.
>
>> Peff, should I add your
>> Signed-off-by to the commit message, or is that not how things are done?
>
> Yes, you can add in any sign-offs that have been explicitly given. It's
> normal to order them chronologically, too (so mine would come first,
> then yours, showing that the patch flowed through me to you; Junio will
> add his at the end).

Thanks, agreed 100% and I have nothing more to add.

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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-11 15:45 ` Duy Nguyen
@ 2018-07-11 16:40   ` Jeff King
  2018-07-11 17:20   ` Junio C Hamano
  1 sibling, 0 replies; 19+ messages in thread
From: Jeff King @ 2018-07-11 16:40 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: wchargin, Git Mailing List

On Wed, Jul 11, 2018 at 05:45:09PM +0200, Duy Nguyen wrote:

> > diff --git a/sha1-name.c b/sha1-name.c
> > index 60d9ef3c7..641ca12f9 100644
> > --- a/sha1-name.c
> > +++ b/sha1-name.c
> > @@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
> >                         struct commit_list *list = NULL;
> >
> >                         for_each_ref(handle_one_ref, &list);
> > +                       head_ref(handle_one_ref, &list);
> 
> When multiple worktrees are used, should we consider all HEADs or just
> current worktree's HEAD?
> 
> This is the latter case, if we should go with the former (I don't
> know, it's a genuine question) then you need one more call:
> other_head_refs().

Oof, I didn't even think about other worktrees. I'd probably say "yes",
as we consider them reachable (and really the intent of this feature
seems to be "find it in any reachable commit").

-Peff

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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-11 15:45 ` Duy Nguyen
  2018-07-11 16:40   ` Jeff King
@ 2018-07-11 17:20   ` Junio C Hamano
  2018-07-11 17:37     ` Duy Nguyen
  1 sibling, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2018-07-11 17:20 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: wchargin, Git Mailing List, Jeff King

Duy Nguyen <pclouds@gmail.com> writes:

>> diff --git a/sha1-name.c b/sha1-name.c
>> index 60d9ef3c7..641ca12f9 100644
>> --- a/sha1-name.c
>> +++ b/sha1-name.c
>> @@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
>>                         struct commit_list *list = NULL;
>>
>>                         for_each_ref(handle_one_ref, &list);
>> +                       head_ref(handle_one_ref, &list);
>
> When multiple worktrees are used, should we consider all HEADs or just
> current worktree's HEAD?

Does for_each_ref() iterate over per-worktree refs (like "bisect",
perhaps)?  If so, then looking in different worktree's HEADs would
make sense, and otherwise not.

I would think that the whole point of detaching HEAD in a separate
worktree is that you can avoid exposing the work you do while
detached to other worktrees by doing so, so from that point of view,
I would probably prefer :/ not to look into other worktrees, but
that is not a very strong preference.  If peeking all over the place
is easier to implement, then a minor information leaking is not
something I'd lose sleep over.

Thanks for bringing up an interesting issue.



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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-11 17:20   ` Junio C Hamano
@ 2018-07-11 17:37     ` Duy Nguyen
  2018-07-11 17:49       ` William Chargin
  0 siblings, 1 reply; 19+ messages in thread
From: Duy Nguyen @ 2018-07-11 17:37 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: William Chargin, Git Mailing List, Jeff King

On Wed, Jul 11, 2018 at 7:20 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Duy Nguyen <pclouds@gmail.com> writes:
>
> >> diff --git a/sha1-name.c b/sha1-name.c
> >> index 60d9ef3c7..641ca12f9 100644
> >> --- a/sha1-name.c
> >> +++ b/sha1-name.c
> >> @@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
> >>                         struct commit_list *list = NULL;
> >>
> >>                         for_each_ref(handle_one_ref, &list);
> >> +                       head_ref(handle_one_ref, &list);
> >
> > When multiple worktrees are used, should we consider all HEADs or just
> > current worktree's HEAD?
>
> Does for_each_ref() iterate over per-worktree refs (like "bisect",
> perhaps)?

No.

> If so, then looking in different worktree's HEADs would
> make sense, and otherwise not.
>
> I would think that the whole point of detaching HEAD in a separate
> worktree is that you can avoid exposing the work you do while
> detached to other worktrees by doing so, so from that point of view,
> I would probably prefer :/ not to look into other worktrees, but
> that is not a very strong preference.

Yeah at least for me worktrees are still quite isolated. Occasionally
I need to peek in a worktree from another one (e.g. if I want to run
tests on current HEAD but do not want to wait for it to finish, I'll
make a new worktree, checking out the same head and run tests there)
but it's really rare. So yeah maybe it's best to stick to current
worktree's HEAD only. At least until someone finds a good case for it.

> If peeking all over the place
> is easier to implement, then a minor information leaking is not
> something I'd lose sleep over.
>
> Thanks for bringing up an interesting issue.
-- 
Duy

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

* Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-11 17:37     ` Duy Nguyen
@ 2018-07-11 17:49       ` William Chargin
  2018-07-12  5:49         ` [PATCH v2] " William Chargin
  0 siblings, 1 reply; 19+ messages in thread
From: William Chargin @ 2018-07-11 17:49 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Junio C Hamano, Git Mailing List, Jeff King

> > Does for_each_ref() iterate over per-worktree refs (like "bisect",
> > perhaps)?
>
> No.

To be clear: it iterates only over the per-worktree refs for the current
worktree. So, if you mark an unreachable commit as "bad" with bisect,
then that commit is reachable (and found by ":/") in the enclosing
worktree only.

With this patch, ":/" now behaves the same way with HEADs, which makes
sense to me. Agreed with the above discussion.

I can add a test for this.

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

* [PATCH v2] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-11 17:49       ` William Chargin
@ 2018-07-12  5:49         ` " William Chargin
  2018-07-12 15:49           ` Jeff King
  2018-07-12 16:04           ` Junio C Hamano
  0 siblings, 2 replies; 19+ messages in thread
From: William Chargin @ 2018-07-12  5:49 UTC (permalink / raw)
  To: git; +Cc: William Chargin, Junio C Hamano, Duy Nguyen, Jeff King

This patch broadens the set of commits matched by ":/" pathspecs to
include commits reachable from HEAD but not any named ref. This avoids
surprising behavior when working with a detached HEAD and trying to
refer to a commit that was recently created and only exists within the
detached state.

If multiple worktrees exist, only the current worktree's HEAD is
considered reachable. This is consistent with the existing behavior for
other per-worktree refs: e.g., bisect refs are considered reachable, but
only within the relevant worktree.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: William Chargin <wchargin@gmail.com>
Based-on-patch-by: Jeff King <peff@peff.net>
---
 Documentation/revisions.txt   |  2 +-
 sha1-name.c                   |  1 +
 t/t4208-log-magic-pathspec.sh | 26 ++++++++++++++++++++++++++
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 7d1bd4409..aa9579eba 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -184,7 +184,7 @@ existing tag object.
   A colon, followed by a slash, followed by a text, names
   a commit whose commit message matches the specified regular expression.
   This name returns the youngest matching commit which is
-  reachable from any ref. The regular expression can match any part of the
+  reachable from any ref, including HEAD. The regular expression can match any part of the
   commit message. To match messages starting with a string, one can use
   e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
   is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a
diff --git a/sha1-name.c b/sha1-name.c
index 60d9ef3c7..641ca12f9 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
 			struct commit_list *list = NULL;
 
 			for_each_ref(handle_one_ref, &list);
+			head_ref(handle_one_ref, &list);
 			commit_list_sort_by_date(&list);
 			return get_oid_oneline(name + 2, oid, list);
 		}
diff --git a/t/t4208-log-magic-pathspec.sh b/t/t4208-log-magic-pathspec.sh
index 62f335b2d..4c8f3b8e1 100755
--- a/t/t4208-log-magic-pathspec.sh
+++ b/t/t4208-log-magic-pathspec.sh
@@ -25,6 +25,32 @@ test_expect_success '"git log :/a -- " should not be ambiguous' '
 	git log :/a --
 '
 
+test_expect_success '"git log :/detached -- " should find a commit only in HEAD' '
+	test_when_finished "git checkout master" &&
+	git checkout --detach &&
+	# Must manually call `test_tick` instead of using `test_commit`,
+	# because the latter additionally creates a tag, which would make
+	# the commit reachable not only via HEAD.
+	test_tick &&
+	git commit --allow-empty -m detached &&
+	test_tick &&
+	git commit --allow-empty -m something-else &&
+	git log :/detached --
+'
+
+test_expect_success '"git log :/detached -- " should not find an orphaned commit' '
+	test_must_fail git log :/detached --
+'
+
+test_expect_success '"git log :/detached -- " should find HEAD only of own worktree' '
+	git worktree add other-tree HEAD &&
+	git -C other-tree checkout --detach &&
+	test_tick &&
+	git -C other-tree commit --allow-empty -m other-detached &&
+	git -C other-tree log :/other-detached -- &&
+	test_must_fail git log :/other-detached --
+'
+
 test_expect_success '"git log -- :/a" should not be ambiguous' '
 	git log -- :/a
 '
-- 
2.18.0.130.g84cda7581


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

* Re: [PATCH v2] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-12  5:49         ` [PATCH v2] " William Chargin
@ 2018-07-12 15:49           ` Jeff King
  2018-07-12 16:04           ` Junio C Hamano
  1 sibling, 0 replies; 19+ messages in thread
From: Jeff King @ 2018-07-12 15:49 UTC (permalink / raw)
  To: William Chargin; +Cc: git, Junio C Hamano, Duy Nguyen

On Wed, Jul 11, 2018 at 10:49:09PM -0700, William Chargin wrote:

> This patch broadens the set of commits matched by ":/" pathspecs to
> include commits reachable from HEAD but not any named ref. This avoids
> surprising behavior when working with a detached HEAD and trying to
> refer to a commit that was recently created and only exists within the
> detached state.
> 
> If multiple worktrees exist, only the current worktree's HEAD is
> considered reachable. This is consistent with the existing behavior for
> other per-worktree refs: e.g., bisect refs are considered reachable, but
> only within the relevant worktree.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> Signed-off-by: William Chargin <wchargin@gmail.com>
> Based-on-patch-by: Jeff King <peff@peff.net>
> ---
>  Documentation/revisions.txt   |  2 +-
>  sha1-name.c                   |  1 +
>  t/t4208-log-magic-pathspec.sh | 26 ++++++++++++++++++++++++++
>  3 files changed, 28 insertions(+), 1 deletion(-)

This one looks good to me. Thanks.

-Peff

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

* Re: [PATCH v2] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-12  5:49         ` [PATCH v2] " William Chargin
  2018-07-12 15:49           ` Jeff King
@ 2018-07-12 16:04           ` Junio C Hamano
  2018-07-12 16:14             ` William Chargin
  1 sibling, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2018-07-12 16:04 UTC (permalink / raw)
  To: William Chargin; +Cc: git, Duy Nguyen, Jeff King

William Chargin <wchargin@gmail.com> writes:

> This patch broadens the set of commits matched by ":/" pathspecs to

As we discussed during the review on v1, ":/<substring in commit>"
is *NOT* pathspec (that is why having these tests in t4208 is wrong
but we are following existing mistakes).  It is a way to specify a
commit object name (unfortunately "extended SHA-1" is the phrase we
often call the various ways to name an object that are implemented
in sha1-name.c).

> include commits reachable from HEAD but not any named ref. This avoids
> surprising behavior when working with a detached HEAD and trying to
> refer to a commit that was recently created and only exists within the
> detached state.
>
> If multiple worktrees exist, only the current worktree's HEAD is
> considered reachable. This is consistent with the existing behavior for
> other per-worktree refs: e.g., bisect refs are considered reachable, but
> only within the relevant worktree.
>
> Signed-off-by: Jeff King <peff@peff.net>
> Signed-off-by: William Chargin <wchargin@gmail.com>
> Based-on-patch-by: Jeff King <peff@peff.net>

Now you have Peff's sign-off for the one-liner code change, the last
one is redundant.

> ---

Other than the above two nits, the patch looks good.  I would have
broken the line after "including HEAD.", but the slightly-long line
is also OK.

>  Documentation/revisions.txt   |  2 +-
>  sha1-name.c                   |  1 +
>  t/t4208-log-magic-pathspec.sh | 26 ++++++++++++++++++++++++++
>  3 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> index 7d1bd4409..aa9579eba 100644
> --- a/Documentation/revisions.txt
> +++ b/Documentation/revisions.txt
> @@ -184,7 +184,7 @@ existing tag object.
>    A colon, followed by a slash, followed by a text, names
>    a commit whose commit message matches the specified regular expression.
>    This name returns the youngest matching commit which is
> -  reachable from any ref. The regular expression can match any part of the
> +  reachable from any ref, including HEAD. The regular expression can match any part of the
>    commit message. To match messages starting with a string, one can use
>    e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
>    is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a
> diff --git a/sha1-name.c b/sha1-name.c
> index 60d9ef3c7..641ca12f9 100644
> --- a/sha1-name.c
> +++ b/sha1-name.c
> @@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
>  			struct commit_list *list = NULL;
>  
>  			for_each_ref(handle_one_ref, &list);
> +			head_ref(handle_one_ref, &list);
>  			commit_list_sort_by_date(&list);
>  			return get_oid_oneline(name + 2, oid, list);
>  		}
> diff --git a/t/t4208-log-magic-pathspec.sh b/t/t4208-log-magic-pathspec.sh
> index 62f335b2d..4c8f3b8e1 100755
> --- a/t/t4208-log-magic-pathspec.sh
> +++ b/t/t4208-log-magic-pathspec.sh
> @@ -25,6 +25,32 @@ test_expect_success '"git log :/a -- " should not be ambiguous' '
>  	git log :/a --
>  '
>  
> +test_expect_success '"git log :/detached -- " should find a commit only in HEAD' '
> +	test_when_finished "git checkout master" &&
> +	git checkout --detach &&
> +	# Must manually call `test_tick` instead of using `test_commit`,
> +	# because the latter additionally creates a tag, which would make
> +	# the commit reachable not only via HEAD.
> +	test_tick &&
> +	git commit --allow-empty -m detached &&
> +	test_tick &&
> +	git commit --allow-empty -m something-else &&
> +	git log :/detached --
> +'
> +
> +test_expect_success '"git log :/detached -- " should not find an orphaned commit' '
> +	test_must_fail git log :/detached --
> +'
> +
> +test_expect_success '"git log :/detached -- " should find HEAD only of own worktree' '
> +	git worktree add other-tree HEAD &&
> +	git -C other-tree checkout --detach &&
> +	test_tick &&
> +	git -C other-tree commit --allow-empty -m other-detached &&
> +	git -C other-tree log :/other-detached -- &&
> +	test_must_fail git log :/other-detached --
> +'
> +
>  test_expect_success '"git log -- :/a" should not be ambiguous' '
>  	git log -- :/a
>  '

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

* Re: [PATCH v2] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-12 16:04           ` Junio C Hamano
@ 2018-07-12 16:14             ` William Chargin
  2018-07-12 19:09               ` Junio C Hamano
  0 siblings, 1 reply; 19+ messages in thread
From: William Chargin @ 2018-07-12 16:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List, Duy Nguyen, Jeff King

> As we discussed during the review on v1, ":/<substring in commit>"
> is *NOT* pathspec (that is why having these tests in t4208 is wrong
> but we are following existing mistakes).

Ah, I understand the terminology better now. Thanks. I'll change the
commit message wording to use "extended SHA-1s" instead of "pathspecs".

> Now you have Peff's sign-off for the one-liner code change, the last
> one is redundant.

Okay: I'll remove the "Based-on-patch-by" line.

> Other than the above two nits, the patch looks good.  I would have
> broken the line after "including HEAD.", but the slightly-long line
> is also OK.

Happy to change this while making the above edits. :-)

Best,
WC

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

* Re: [PATCH v2] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-12 16:14             ` William Chargin
@ 2018-07-12 19:09               ` Junio C Hamano
  2018-07-12 20:01                 ` William Chargin
  0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2018-07-12 19:09 UTC (permalink / raw)
  To: William Chargin; +Cc: Git Mailing List, Duy Nguyen, Jeff King

William Chargin <wchargin@gmail.com> writes:

>> As we discussed during the review on v1, ":/<substring in commit>"
>> is *NOT* pathspec (that is why having these tests in t4208 is wrong
>> but we are following existing mistakes).
>
> Ah, I understand the terminology better now. Thanks. I'll change the
> commit message wording to use "extended SHA-1s" instead of "pathspecs".
>
>> Now you have Peff's sign-off for the one-liner code change, the last
>> one is redundant.
>
> Okay: I'll remove the "Based-on-patch-by" line.
>
>> Other than the above two nits, the patch looks good.  I would have
>> broken the line after "including HEAD.", but the slightly-long line
>> is also OK.
>
> Happy to change this while making the above edits. :-)

Let's save a round-trip.  Here is what I'd queue for now, and you
can just say "looks good" if you agree with the result, or send an
updated version ;-).

Thanks for working on this.

-- >8 --
From: William Chargin <wchargin@gmail.com>
Date: Wed, 11 Jul 2018 22:49:09 -0700
Subject: [PATCH] sha1-name.c: for ":/", find detached HEAD commits

This patch broadens the set of commits matched by ":/<pattern>" to
include commits reachable from HEAD but not any named ref. This avoids
surprising behavior when working with a detached HEAD and trying to
refer to a commit that was recently created and only exists within the
detached state.

If multiple worktrees exist, only the current worktree's HEAD is
considered reachable. This is consistent with the existing behavior for
other per-worktree refs: e.g., bisect refs are considered reachable, but
only within the relevant worktree.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: William Chargin <wchargin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/revisions.txt   |  3 ++-
 sha1_name.c                   |  1 +
 t/t4208-log-magic-pathspec.sh | 26 ++++++++++++++++++++++++++
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index dfcc49c72c..0845c3f590 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -180,7 +180,8 @@ existing tag object.
   A colon, followed by a slash, followed by a text, names
   a commit whose commit message matches the specified regular expression.
   This name returns the youngest matching commit which is
-  reachable from any ref. The regular expression can match any part of the
+  reachable from any ref, including HEAD.
+  The regular expression can match any part of the
   commit message. To match messages starting with a string, one can use
   e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
   is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a
diff --git a/sha1_name.c b/sha1_name.c
index 611c7d24dd..19f66713e1 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1649,6 +1649,7 @@ static int get_oid_with_context_1(const char *name,
 			struct commit_list *list = NULL;
 
 			for_each_ref(handle_one_ref, &list);
+			head_ref(handle_one_ref, &list);
 			commit_list_sort_by_date(&list);
 			return get_oid_oneline(name + 2, oid, list);
 		}
diff --git a/t/t4208-log-magic-pathspec.sh b/t/t4208-log-magic-pathspec.sh
index a1705f70cf..69643d101d 100755
--- a/t/t4208-log-magic-pathspec.sh
+++ b/t/t4208-log-magic-pathspec.sh
@@ -25,6 +25,32 @@ test_expect_success '"git log :/a -- " should not be ambiguous' '
 	git log :/a --
 '
 
+test_expect_success '"git log :/detached -- " should find a commit only in HEAD' '
+	test_when_finished "git checkout master" &&
+	git checkout --detach &&
+	# Must manually call `test_tick` instead of using `test_commit`,
+	# because the latter additionally creates a tag, which would make
+	# the commit reachable not only via HEAD.
+	test_tick &&
+	git commit --allow-empty -m detached &&
+	test_tick &&
+	git commit --allow-empty -m something-else &&
+	git log :/detached --
+'
+
+test_expect_success '"git log :/detached -- " should not find an orphaned commit' '
+	test_must_fail git log :/detached --
+'
+
+test_expect_success '"git log :/detached -- " should find HEAD only of own worktree' '
+	git worktree add other-tree HEAD &&
+	git -C other-tree checkout --detach &&
+	test_tick &&
+	git -C other-tree commit --allow-empty -m other-detached &&
+	git -C other-tree log :/other-detached -- &&
+	test_must_fail git log :/other-detached --
+'
+
 test_expect_success '"git log -- :/a" should not be ambiguous' '
 	git log -- :/a
 '
-- 
2.18.0-129-ge3331758f1


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

* Re: [PATCH v2] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-12 19:09               ` Junio C Hamano
@ 2018-07-12 20:01                 ` William Chargin
  2018-07-13 19:24                   ` Jeff King
  0 siblings, 1 reply; 19+ messages in thread
From: William Chargin @ 2018-07-12 20:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List, Duy Nguyen, Jeff King

Contents look good to me. I don't understand why the file name in your
patch is sha1_name.c as opposed to sha1-name.c (I see e5e5e0883 from
2018-04-10, but that sounds pretty old), but I trust that whatever
you're doing there is correct.

> Thanks for working on this.

You're quite welcome. Thanks to you, Peff, and Duy for your help. This
was a pleasant experience for me as a new contributor. :-)

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

* Re: [PATCH v2] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-12 20:01                 ` William Chargin
@ 2018-07-13 19:24                   ` Jeff King
  2018-07-13 19:40                     ` William Chargin
  0 siblings, 1 reply; 19+ messages in thread
From: Jeff King @ 2018-07-13 19:24 UTC (permalink / raw)
  To: William Chargin; +Cc: Junio C Hamano, Git Mailing List, Duy Nguyen

On Thu, Jul 12, 2018 at 01:01:23PM -0700, William Chargin wrote:

> Contents look good to me. I don't understand why the file name in your
> patch is sha1_name.c as opposed to sha1-name.c (I see e5e5e0883 from
> 2018-04-10, but that sounds pretty old), but I trust that whatever
> you're doing there is correct.

Junio typically applies bugfixes as close to the bug-source as possible,
which allows them to be merged-up into various releases (rather than
cherry-picked, which would be required if built on top of 'master').

Ideally this is directly on top of the commit that introduced the bug,
though for an ancient bug like this, it's not worth the effort. It looks
like he applied it on the 2.16 maint branch, which predates e5e5e0883.
When it's merged up, the resolution will handle the rename (probably
even automatically due to Git's rename detection).

> > Thanks for working on this.
> 
> You're quite welcome. Thanks to you, Peff, and Duy for your help. This
> was a pleasant experience for me as a new contributor. :-)

Great. Please come back anytime. :)

-Peff

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

* Re: [PATCH v2] sha1-name.c: for ":/", find detached HEAD commits
  2018-07-13 19:24                   ` Jeff King
@ 2018-07-13 19:40                     ` William Chargin
  0 siblings, 0 replies; 19+ messages in thread
From: William Chargin @ 2018-07-13 19:40 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, Git Mailing List, Duy Nguyen

> Junio typically applies bugfixes as close to the bug-source as possible,
> which allows them to be merged-up into various releases (rather than
> cherry-picked, which would be required if built on top of 'master').
>
> Ideally this is directly on top of the commit that introduced the bug,
> though for an ancient bug like this, it's not worth the effort. It looks
> like he applied it on the 2.16 maint branch, which predates e5e5e0883.
> When it's merged up, the resolution will handle the rename (probably
> even automatically due to Git's rename detection).

That makes sense. Thanks for the explanation.

> Great. Please come back anytime. :)

Will do!

Best,
WC

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

end of thread, back to index

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-10 15:41 [PATCH] sha1-name.c: for ":/", find detached HEAD commits William Chargin
2018-07-10 17:54 ` Jeff King
2018-07-10 19:06 ` Junio C Hamano
2018-07-11  6:18   ` William Chargin
2018-07-11 12:32     ` Jeff King
2018-07-11 16:34       ` Junio C Hamano
2018-07-11 15:45 ` Duy Nguyen
2018-07-11 16:40   ` Jeff King
2018-07-11 17:20   ` Junio C Hamano
2018-07-11 17:37     ` Duy Nguyen
2018-07-11 17:49       ` William Chargin
2018-07-12  5:49         ` [PATCH v2] " William Chargin
2018-07-12 15:49           ` Jeff King
2018-07-12 16:04           ` Junio C Hamano
2018-07-12 16:14             ` William Chargin
2018-07-12 19:09               ` Junio C Hamano
2018-07-12 20:01                 ` William Chargin
2018-07-13 19:24                   ` Jeff King
2018-07-13 19:40                     ` William Chargin

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

Archives are clonable:
	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

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

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