* Re: [PATCH/RFC] sparse-checkout: take care of "--end-of-options" in set/add
From: Junio C Hamano @ 2023-12-21 22:04 UTC (permalink / raw)
To: Jeff King; +Cc: Josh Steadmon, git
In-Reply-To: <20231221214550.GD1446091@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Right, that is the "gotcha" I mentioned in my other email. Though that
> is the way it has behaved historically, my argument is that users are
> unreasonable to expect it to work:
>
> 1. It is not consistent with the rest of Git commands.
>
> 2. It is inconsistent with respect to existing options (and is an
> accident waiting to happen when new options are added).
>
> So I'd consider it a bug-fix.
So the counter-proposal here is just to drop KEEP_UNKNOWN_OPT and
deliberately break them^W^W^Wrealign their expectations?
I do not have much stake in sparse-checkout, so I am fine with that
direction. But I suspect other folks on the list would have users
of their own who would rather loudly complain to them if we broke
them ;-)
I'll see how bad the fallout would be if we go that route, using the
test modification I made for the previous rounds as yardsticks.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/9] CodingGuidelines: write punctuation marks
From: Junio C Hamano @ 2023-12-21 21:57 UTC (permalink / raw)
To: Josh Soref; +Cc: git, Elijah Newren, René Scharfe, Phillip Wood
In-Reply-To: <CACZqfqAtT_M8T3AxbgZrkgi3GtQ=JZLu4wvh3O0C9dFvCU3rWg@mail.gmail.com>
Josh Soref <jsoref@gmail.com> writes:
> Junio C Hamano wrote:
>> Nobody seems to have commented on this step in the previous round,
>> but I do not understand what you mean by ...
>>
>> > From: Josh Soref <jsoref@gmail.com>
>> > - Match style in Release Notes
>>
>> ... at all. The patch text is fine, though.
>
> https://github.com/gitgitgadget/git/blob/692be87cbba55e8488f805d236f2ad50483bd7d5/Documentation/RelNotes/2.43.0.txt#L221
You mean just a single mention of the phrase? If so, you should
pinpoint it, e.g. "The release notes for Git 2.43 calls them
'punctuation marks', so let's use that here, too" or something like
that.
Unless you are sure that all the issues of Release Notes have and
will consistently say "punctuation marks" and never say
"punctuations", that is.
^ permalink raw reply
* Re: [PATCH v2 5/9] SubmittingPatches: update extra tags list
From: Josh Soref @ 2023-12-21 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Elijah Newren, René Scharfe, Phillip Wood
In-Reply-To: <xmqq4jgbl0iz.fsf@gitster.g>
Junio C Hamano wrote:
> "Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > +. `Co-authored-by:` is used to indicate that people exchanged drafts
> > + of a patch before submitting it.
>
> I am afraid this misses the essence of what Co-authoring means.
> You may have shared your draft as FYI to your colleagues, and they
> may have tweaked phrasing and responded with their reviews to help
> you improve _your_ work, but that may not make them your Co-authors.
>
> I think the "intent" counts more. If people closely worked
> together, exchanging drafts and agreeing on the final version among
> themselves before submitting, with the understanding that they share
> the authorship credit/blame, they are Co-authors.
. `Co-authored-by:` is used to indicate that people collaborated on the
contents of a patch before submitting it.
?
^ permalink raw reply
* Re: [PATCH v2 1/9] CodingGuidelines: move period inside parentheses
From: Josh Soref @ 2023-12-21 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Elijah Newren, René Scharfe, Phillip Wood
In-Reply-To: <xmqqedffl13r.fsf@gitster.g>
Junio C Hamano wrote:
> > From: Josh Soref <jsoref@gmail.com>
> >
> > The contents within parenthesis should be omittable without resulting
> > in broken text.
> >
> > Eliding the parenthesis left a period to end a run without any content.
>
> Nobody seems to have commented on this one in the previous round,
> but quite honestly, for this particular instance, I suspect that it
> may become easier to read if we just lost these parentheses, as the
> next sentence "You do not have to include more than ..." is just a
> bit of extra material to support the first sentence like the one we
> see in the parentheses. Alternatively, moving that "You do not have
> to" also inside the same parentheses might work slightly better.
> It might be even easier to follow if we moved the list of "approved
> headers" (and the "You do not have to ... more than one" note that
> supports the "currently approved list") totally out of line by
> making it a side note.
I think, in principle, it'd be better if it was its own thing, but the
structure of this entire section makes this really hard -- I certainly
can't imagine a way to do it.
The laziest fix is:
- The first #include in C files, except in platform specific compat/
implementations and sha1dc/, must be one of "git-compat-util.h",
"builtin.h", "t/helper/test-tool.h", "xdiff/xinclude.h", or
"reftable/system.h".
Beyond that, I don't understand how to parse:
You do not have to include more than one of these.
(Sorry, I'd like to be slightly ignorant of the C parts of git --
let's ignore that I've been blamed for at least one change to them --
so, I'm not going to look.)
^ permalink raw reply
* Re: [PATCH v2 2/9] CodingGuidelines: write punctuation marks
From: Josh Soref @ 2023-12-21 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Elijah Newren, René Scharfe, Phillip Wood
In-Reply-To: <xmqqplyzl1e8.fsf@gitster.g>
Junio C Hamano wrote:
> Nobody seems to have commented on this step in the previous round,
> but I do not understand what you mean by ...
>
> > From: Josh Soref <jsoref@gmail.com>
> > - Match style in Release Notes
>
> ... at all. The patch text is fine, though.
https://github.com/gitgitgadget/git/blob/692be87cbba55e8488f805d236f2ad50483bd7d5/Documentation/RelNotes/2.43.0.txt#L221
^ permalink raw reply
* Re: [PATCH/RFC] sparse-checkout: take care of "--end-of-options" in set/add
From: Jeff King @ 2023-12-21 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh Steadmon, git
In-Reply-To: <xmqqsf3vmqug.fsf@gitster.g>
On Thu, Dec 21, 2023 at 09:02:15AM -0800, Junio C Hamano wrote:
> > Yeah. I think it is in the same boat as the other two, in that I believe
> > that the KEEP_UNKNOWN_OPT flag is counter-productive and should just be
> > dropped.
>
> If we dropped KEEP_UNKNOWN_OPT, however, the pattern that is
> currently accepted will stop working, e.g.,
>
> $ git sparse-checkout [add/set] --[no-]cone --foo bar
>
> as we would barf with "--foo: unknown option", and the users who are
> used to this sloppy command line parsing we had for the past few
> years must now write "--end-of-options" before "--foo". After all,
> the reason why the original authors of this code used KEEP_UNKNOWN
> is likely to deal with path patterns that begin with dashes.
Right, that is the "gotcha" I mentioned in my other email. Though that
is the way it has behaved historically, my argument is that users are
unreasonable to expect it to work:
1. It is not consistent with the rest of Git commands.
2. It is inconsistent with respect to existing options (and is an
accident waiting to happen when new options are added).
So I'd consider it a bug-fix.
> The patch in the message that started this thread may not be
> correct, either, I am afraid. For either of these:
>
> $ git sparse-checkout [add/set] --[no-]cone foo --end-of-options bar
> $ git sparse-checkout [add/set] --[no-]cone --foo --end-of-options bar
>
> we would see that "foo" (or "--foo") is not "--end-of-options", and
> we end up using three patterns "foo" (or "--foo"),
> "--end-of-options", and "bar", I suspect. I wonder if we should
> notice the "foo" or "--foo" that were not understood and error out,
> instead.
Yes, I agree that "--foo --end-of-options" should barf. And of course
that happens naturally if you just let parse-options do its job by not
passing the KEEP_UNKNOWN_OPT flag. ;)
I'm not sure about "foo". We do allow out-of-order options/args, so
isn't it correct to keep it as a non-option argument?
> But after all, it is not absolutely necessary to notice and barf.
> The ONLY practical use of the "--end-of-options" mechanism is to
> allow us to write (this applies to any git subcommand):
>
> #!/bin/sh
> git cmd --hard --coded --options --end-of-options "$@"
>
> in scripts to protect the intended operation from mistaking the
> end-user input as options. And with a script written carefully to
> do so, all the args that appear before "--end-of-options" would be
> recognizable by the command line parser.
Yes, but if you misspell "--otpions", it magically becomes a parameter
rather than having the command barf and complain. That is not the end of
the world, but it is unfriendly and inconsistent with the rest of Git.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] archive: "--list" does not take further options
From: Jeff King @ 2023-12-21 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, git
In-Reply-To: <xmqqmsu3mnix.fsf@gitster.g>
On Thu, Dec 21, 2023 at 10:13:58AM -0800, Junio C Hamano wrote:
> Thanks, both. Just to tie the loose end, let me queue this and
> merge it to 'next'.
>
> ----- >8 --------- >8 --------- >8 -----
> Subject: [PATCH] archive: "--list" does not take further options
This looks fine to me. It does mean that this sequence of commands no
longer works:
[let's try to make a "foo" archive]
$ git archive --format=foo HEAD
fatal: Unknown archive format 'foo'
[oops, that didn't work. What formats are supported?]
$ !! --list
git archive --format=foo HEAD --list
tar
tgz
tar.gz
zip
I think that's OK in practice. The increased error checking is worth it
(and matches many other commands, which tend to warn about confusing
extra bits).
-Peff
^ permalink raw reply
* Re: [PATCH] t1006: add tests for %(objectsize:disk)
From: Jeff King @ 2023-12-21 21:30 UTC (permalink / raw)
To: René Scharfe
Cc: git, Ondrej Pohorelsky, brian m . carlson, Junio C Hamano
In-Reply-To: <d44cb8e7-ffce-4184-b9b5-6bb56705dcd1@web.de>
On Thu, Dec 21, 2023 at 01:19:53PM +0100, René Scharfe wrote:
> I think we can do it even in shell, especially if...
> [...]
Yeah, your conversion looks accurate. I do wonder if it is worth golfing
further, though. If it were a process invocation per object, I'd
definitely say the efficiency gain is worth it. But dropping one process
from the whole test isn't that exciting either way.
> (sort -r), then we don't need to carry the oid forward:
>
> sort -nr <idx.raw >idx.sorted &&
> packsz=$(test_file_size "${idx%.idx}.pack") &&
> end=$((packsz - rawsz)) &&
> awk -v end="$end" "
> { print \$2, end - \$1; end = \$1 }
> " idx.sorted ||
>
> And at that point it should be easy to use a shell loop instead of awk:
>
> while read start oid rest
> do
> size=$((end - start)) &&
> end=$start &&
> echo "$oid $size" ||
> return 1
> done <idx.sorted
The one thing I do like is that we don't have to escape anything inside
an awk program that is forced to use double-quotes. ;)
> Should we deduplicate here, like cat-file does (i.e. use "sort -u")?
> Having the same object in multiple places for whatever reason would not
> be a cause for reporting an error in this test, I would think.
No, for the reasons I said in the commit message: if an object exists in
multiple places the test is already potentially invalid, as Git does not
promise which version it will use. So it might work racily, or it might
work for now but be fragile. By not de-duplicating, we make sure the
test's assumption holds.
> One more thing: We can do the work of the first awk invocation in the
> already existing loop as well:
> [...]
> ... but the substitutions are a bit awkward:
>
> find .git/objects/?? -type f |
> while read path
> do
> basename=${path##*/} &&
> dirname=${path%/$basename} &&
> oid="${dirname#.git/objects/}${basename}" &&
> size=$(test_file_size "$path") &&
> echo "$oid $size" ||
> return 1
> done &&
>
> The avoided awk invocation might be worth the trouble, though.
Yeah, I briefly considered whether it would be possible in pure shell,
but didn't get very far before assuming it was going to be ugly. Thank
you for confirming. ;)
Again, if we were doing one awk per object, I'd try to avoid it. But
since we can cover all objects in a single pass, I think it's OK.
-Peff
^ permalink raw reply
* Re: [PATCH v2 7/9] SubmittingPatches: clarify GitHub visual
From: Junio C Hamano @ 2023-12-21 21:27 UTC (permalink / raw)
To: Josh Soref via GitGitGadget
Cc: git, Elijah Newren, René Scharfe, Phillip Wood, Josh Soref
In-Reply-To: <cdb5fd0957fee7ce8c19720f588da96898cd3dc9.1703176866.git.gitgitgadget@gmail.com>
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Josh Soref <jsoref@gmail.com>
>
> GitHub has two general forms for its states, sometimes they're a simple
> colored object (e.g. green check or red x), and sometimes there's also a
> colored container (e.g. green box or red circle) with containing that
> object (e.g. check or x).
>
> That's a lot of words to try to describe things, but in general, the key
> for a failure is that it's recognized as an `x` and that it's associated
> with the color red -- the color of course is problematic for people who
> are red-green color-blind, but that's why they are paired with distinct
> shapes.
>
> Using the term `cross` doesn't really help.
I am not sure if this is accurate. Using `x` alone does not help,
either.
I think this was raised during the review of the initial round, but
...
> If a branch did not pass all test cases then it is marked with a red
> -cross. In that case you can click on the failing job and navigate to
> ++x+. In that case you can click on the failing job and navigate to
... it would help if we added something like ", instead of a green
checkmark" after "with a red x". It will make the contrast with the
succeeding case stronger. IOW, we can take advantage of the idea to
use "pair with distinct shapes and colors" ourselves.
> "ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You
> can also download "Artifacts" which are tarred (or zipped) archives
> with test data relevant for debugging.
^ permalink raw reply
* Re: [PATCH v2 6/9] SubmittingPatches: improve extra tags advice
From: Junio C Hamano @ 2023-12-21 21:18 UTC (permalink / raw)
To: Josh Soref via GitGitGadget
Cc: git, Elijah Newren, René Scharfe, Phillip Wood, Josh Soref
In-Reply-To: <8f16c7caa7366cab22ad332c402f80823add8224.1703176866.git.gitgitgadget@gmail.com>
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Josh Soref <jsoref@gmail.com>
>
> Current statistics show a strong preference to only capitalize the first
> letter in a hyphenated tag, but that some guidance would be helpful:
>
> git log |
> perl -ne 'next unless /^\s+(?:Signed-[oO]ff|Acked)-[bB]y:/;
> s/^\s+//;s/:.*/:/;print'|
> sort|uniq -c|sort -n
> 2 Signed-off-By:
> 4 Signed-Off-by:
> 22 Acked-By:
> 47 Signed-Off-By:
> 2202 Acked-by:
> 95315 Signed-off-by:
>
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> Documentation/SubmittingPatches | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 31878cb70b7..4476b52a50f 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -368,6 +368,9 @@ While you can also create your own trailer if the situation warrants it, we
> encourage you to instead use one of the common trailers in this project
> highlighted above.
>
> +Extra tags should only capitalize the very first letter, i.e. favor
> +"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".
Drop "Extra", perhaps? The sentence before already discourages any
extra ones, and what this sentence teaches the contributors is to
avoud spelling variation when to spell the common ones.
> [[git-tools]]
> === Generate your patch using Git tools out of your commits.
^ permalink raw reply
* Re: [PATCH v2 5/9] SubmittingPatches: update extra tags list
From: Junio C Hamano @ 2023-12-21 21:16 UTC (permalink / raw)
To: Josh Soref via GitGitGadget
Cc: git, Elijah Newren, René Scharfe, Phillip Wood, Josh Soref
In-Reply-To: <8848572fe2c7432ede85e042bc2558fd8b3e8b1d.1703176866.git.gitgitgadget@gmail.com>
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> +. `Co-authored-by:` is used to indicate that people exchanged drafts
> + of a patch before submitting it.
I am afraid this misses the essence of what Co-authoring means.
You may have shared your draft as FYI to your colleagues, and they
may have tweaked phrasing and responded with their reviews to help
you improve _your_ work, but that may not make them your Co-authors.
I think the "intent" counts more. If people closely worked
together, exchanging drafts and agreeing on the final version among
themselves before submitting, with the understanding that they share
the authorship credit/blame, they are Co-authors.
> +. `Helped-by:` is used to credit someone who suggested ideas for
> + changes without providing the precise changes in patch form.
> +. `Mentored-by:` is used to credit someone with helping develop a
> + patch as part of a mentorship program (e.g., GSoC or Outreachy).
Nicely differentiated.
^ permalink raw reply
* Re: [PATCH v2 3/9] SubmittingPatches: drop ref to "What's in git.git"
From: Junio C Hamano @ 2023-12-21 21:09 UTC (permalink / raw)
To: Josh Soref via GitGitGadget
Cc: git, Elijah Newren, René Scharfe, Phillip Wood, Josh Soref
In-Reply-To: <22d66c5b78a6930e195141df848266cac099ca08.1703176866.git.gitgitgadget@gmail.com>
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Josh Soref <jsoref@gmail.com>
>
> "What's in git.git" was last seen in 2010:
> https://lore.kernel.org/git/?q=%22what%27s+in+git.git%22
> https://lore.kernel.org/git/7vaavikg72.fsf@alter.siamese.dyndns.org/
>
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> Documentation/SubmittingPatches | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks. I stopped doing these long time ago, as there were certain
overlaps with "What's cooking" that lists the topics that have
graduated in a separate section.
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index bce7f97815c..32e90238777 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -570,7 +570,7 @@ their trees themselves.
> master).
>
> * Read the Git mailing list, the maintainer regularly posts messages
> - entitled "What's cooking in git.git" and "What's in git.git" giving
> + entitled "What's cooking in git.git" giving
> the status of various proposed changes.
>
> == GitHub CI[[GHCI]]
^ permalink raw reply
* Re: [PATCH v2 1/9] CodingGuidelines: move period inside parentheses
From: Junio C Hamano @ 2023-12-21 21:03 UTC (permalink / raw)
To: Josh Soref via GitGitGadget
Cc: git, Elijah Newren, René Scharfe, Phillip Wood, Josh Soref
In-Reply-To: <b9a8eb6aa4e87cd96fbf2b5d514350508076d756.1703176866.git.gitgitgadget@gmail.com>
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Josh Soref <jsoref@gmail.com>
>
> The contents within parenthesis should be omittable without resulting
> in broken text.
>
> Eliding the parenthesis left a period to end a run without any content.
Nobody seems to have commented on this one in the previous round,
but quite honestly, for this particular instance, I suspect that it
may become easier to read if we just lost these parentheses, as the
next sentence "You do not have to include more than ..." is just a
bit of extra material to support the first sentence like the one we
see in the parentheses. Alternatively, moving that "You do not have
to" also inside the same parentheses might work slightly better.
It might be even easier to follow if we moved the list of "approved
headers" (and the "You do not have to ... more than one" note that
supports the "currently approved list") totally out of line by
making it a side note.
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> Documentation/CodingGuidelines | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 8ed517a5ca0..af94ed3a75d 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -450,7 +450,7 @@ For C programs:
> one of the approved headers that includes it first for you. (The
> approved headers currently include "builtin.h",
> "t/helper/test-tool.h", "xdiff/xinclude.h", or
> - "reftable/system.h"). You do not have to include more than one of
> + "reftable/system.h".) You do not have to include more than one of
> these.
>
> - A C file must directly include the header files that declare the
^ permalink raw reply
* rebase invoking pre-commit
From: Sean Allred @ 2023-12-21 20:58 UTC (permalink / raw)
To: Git List
Is there a current reason why pre-commit shouldn't be invoked during
rebase, or is this just waiting for a reviewable patch?
This was brought up before at [1] in 2015, but that thread so old at
this point that it seemed prudent to double-check before investing time
in a developing and testing a patch.
[1]: https://lore.kernel.org/git/1m55i3m.1fum4zo1fpnhncM%25lists@haller-berlin.de/
--
Sean Allred
^ permalink raw reply
* Re: [PATCH v2 2/9] CodingGuidelines: write punctuation marks
From: Junio C Hamano @ 2023-12-21 20:57 UTC (permalink / raw)
To: Josh Soref via GitGitGadget
Cc: git, Elijah Newren, René Scharfe, Phillip Wood, Josh Soref
In-Reply-To: <c0db8336e519cb43767effbe842dc8b97f914a4b.1703176866.git.gitgitgadget@gmail.com>
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
Nobody seems to have commented on this step in the previous round,
but I do not understand what you mean by ...
> From: Josh Soref <jsoref@gmail.com>
>
> - Match style in Release Notes
... at all. The patch text is fine, though.
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> Documentation/CodingGuidelines | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index af94ed3a75d..578587a4715 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -578,7 +578,7 @@ Externally Visible Names
> . The variable name describes the effect of tweaking this knob.
>
> The section and variable names that consist of multiple words are
> - formed by concatenating the words without punctuations (e.g. `-`),
> + formed by concatenating the words without punctuation marks (e.g. `-`),
> and are broken using bumpyCaps in documentation as a hint to the
> reader.
^ permalink raw reply
* Re: [PATCH 2/2] ref-filter: support filtering of operational refs
From: Junio C Hamano @ 2023-12-21 20:40 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, ps, christian.couder
In-Reply-To: <20231221170715.110565-3-karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
> With the upcoming introduction of the reftable backend, it becomes ever
> so important to provide the necessary tooling for printing all refs
> associated with a repository.
We have pseudoref (those all caps files outside the refs/ hierarchy)
as an official term defined in the glossary, and Patrick's reftable
work based on Han-Wen's work revealed the need to treat FETCH_HEAD
and MERGE_HEAD as "even more pecurilar than pseudorefs" that need
different term (tentatively called "special refs"). Please avoid
coming up with yet another random name "operational" without
discussing.
With a quick look at the table in this patch, "pseudorefs" appears
to be the closest word that people are already familiar with, I
think. A lot more reasonable thing to do may be to scan the
$GIT_DIR for files whose name satisfy refs.c:is_pseudoref_syntax()
and list them, instead of having a hardcoded list of these special
refs. In addition, when reftable and other backends that can
natively store things outside refs/ hierarchy is in use, they ought
to know what they have so enumerating these would not be an issue
for them without having such a hardcoded table of names.
^ permalink raw reply
* Re: Unable to install git-2.43.0 from source on macOS Big Sur 11.7.10
From: Jonathan Abrams @ 2023-12-21 19:40 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git@vger.kernel.org
In-Reply-To: <CAPig+cQgTNq8rKiXm_dDha+Rz-=Z9O4_gvWLWdcPJe1yp=hQ8Q@mail.gmail.com>
After deactivating the conda environment, I get a different error. The commands I entered are:
conda deactivate
make configure
./configure --prefix=/usr
make V=1 all doc
This ends with the following error.
/usr/bin/perl ./build-docdep.perl >doc.dep
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../ GIT-VERSION-FILE
make[2]: `GIT-VERSION-FILE' is up to date.
fatal: not a git repository (or any of the parent directories): .git
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../ GIT-VERSION-FILE
make[2]: `GIT-VERSION-FILE' is up to date.
* new asciidoc flags
asciidoc -f asciidoc.conf -amanmanual='Git Manual' -amansource='Git 2.43.0' -arevdate='' -b xhtml11 -d manpage -o git-add.html git-add.txt
make[1]: asciidoc: No such file or directory
make[1]: *** [git-add.html] Error 1
make: *** [doc] Error 2
Your suggestion to run the following commands results in a different error. The suggested commands were:
cd git-2.43.0
conda deactivate
make distclean
make all
This ends with the following error.
GIT_VERSION = 2.43.0
* new build flags
CC oss-fuzz/fuzz-commit-graph.o
CC oss-fuzz/fuzz-pack-headers.o
CC oss-fuzz/fuzz-pack-idx.o
CC daemon.o
* new link flags
CC common-main.o
In file included from common-main.c:3:
./gettext.h:17:11: fatal error: 'libintl.h' file not found
# include <libintl.h>
^~~~~~~~~~~
1 error generated.
make: *** [common-main.o] Error 1
Looking around line 17 in ./gettext.h, I see this.
#ifndef NO_GETTEXT
# include <libintl.h>
Executing gettext --version returned nothing. I then downloaded gettext and installed it using the following commands.
./configure
make
make check
sudo make install
I then executed your suggested commands again.
conda deactivate
make distclean
make all
sudo make install
This installed GIT. Thank you for your guidance!
Jonathan S. Abrams
^ permalink raw reply
* Re: [PATCH/RFC] sparse-checkout: take care of "--end-of-options" in set/add
From: Junio C Hamano @ 2023-12-21 18:20 UTC (permalink / raw)
To: Jeff King; +Cc: Derrick Stolee, git, Josh Steadmon
In-Reply-To: <20231221083643.GA545870@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Which would mean that simply dropping --end-of-options from the list, as
> your patch does, would be similarly unsafe. It is papering over the
> problem of:
>
> git sparse-checkout --end-of-options foo
>
> but leaving:
>
> git sparse-checkout --end-of-options --foo
>
> broken.
Hmph, I do not understand. The latter case we want to take "--foo"
as the sole parameter to the subcommand, no?
> But the plot thickens! Curiously, in both of these cases, we do not do
> any further parsing of the options at all. We just treat them as
> pattern arguments with no special meaning.
Exactly.
> So your patch is actually OK, but I would argue that the correct fix
> here is to drop the use of PARSE_OPT_KEEP_UNKNOWN_OPT at all. I cannot
> find any indication in the history on why it was ever used. It was added
> when the command was converted to parse-options in 7bffca95ea
> (sparse-checkout: add '--stdin' option to set subcommand, 2019-11-21).
> Back then it was just called KEEP_UNKNOWN. Later it was renamed to
> KEEP_UNKNOWN_OPT in 99d86d60e5 (parse-options: PARSE_OPT_KEEP_UNKNOWN
> only applies to --options, 2022-08-19) to clarify that it was only about
> dashed options; we always keep non-option arguments.
Yes.
> So looking at that original patch, it makes me think that the author was
> confused about the mis-named option, and really just wanted to keep the
> non-option arguments. We never should have used the flag all along (and
> the other cases were cargo-culted within the file).
That is something only the original author can answer, by my working
theory has been they wanted to have a cheap way to allow any string,
even the ones that happen to begin with a dash, to be passed as one
of the patterns.
> There is one minor gotcha, though. Unlike most other Git commands,
> sparse-checkout will happily accept random option names and treat them
> as non-option arguments. E.g. this works:
>
> git sparse-checkout add --foo --bar
>
> and will add "--foo" and "--bar" as patterns. If we remove the flag,
> we'd be breaking that.
Exactly. The user _should_ protect these "patterns" by using
"--end-of-options" before "--foo" above, but we have been taking the
patterns with such a loose parser for quite some time, so tightening
would be taken as a regression X-<.
> But I'd argue that anybody relying on that is
> asking for trouble. For example, this does not work in the same way:
>
> git sparse-checkout add --skip-checks --foo
>
> because "--skip-checks" is a real option. Ditto for any other options,
> including those we add in the future. If you don't trust the contents of
> your arguments, you should be using "--" or "--end-of-options" to
> communicate the intent to the command.
Exactly. My response to the other message, with a new test,
summarizes my position.
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] archive: "--list" does not take further options
From: Junio C Hamano @ 2023-12-21 18:13 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, git
In-Reply-To: <20231221085948.GD545870@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Dec 21, 2023 at 08:30:36AM +0100, René Scharfe wrote:
>> ...
>> Don't we have one? It would affect other unsupported options as well,
>> and this seems to work just fine, e.g.:
>> ...
> Right. The whole idea of upload-archive is to spawn a separate writer
> process and mux the conversation (including errors) back over the wire.
Thanks, both. Just to tie the loose end, let me queue this and
merge it to 'next'.
----- >8 --------- >8 --------- >8 -----
Subject: [PATCH] archive: "--list" does not take further options
"git archive --list blah" should notice an extra command line
parameter that goes unused. Make it so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
archive.c | 2 ++
t/t5000-tar-tree.sh | 10 ++++++++++
2 files changed, 12 insertions(+)
diff --git a/archive.c b/archive.c
index ca11db185b..8da820d1ce 100644
--- a/archive.c
+++ b/archive.c
@@ -685,6 +685,8 @@ static int parse_archive_args(int argc, const char **argv,
base = "";
if (list) {
+ if (argc)
+ die(_("extra command line parameter '%s'"), *argv);
for (i = 0; i < nr_archivers; i++)
if (!is_remote || archivers[i]->flags & ARCHIVER_REMOTE)
printf("%s\n", archivers[i]->name);
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 4b4c3315d8..72b8d0ff02 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -124,6 +124,16 @@ test_expect_success 'setup' '
EOF
'
+test_expect_success '--list notices extra parameters' '
+ test_must_fail git archive --list blah &&
+ test_must_fail git archive --remote=. --list blah
+'
+
+test_expect_success 'end-of-options is correctly eaten' '
+ git archive --list --end-of-options &&
+ git archive --remote=. --list --end-of-options
+'
+
test_expect_success 'populate workdir' '
mkdir a &&
echo simple textfile >a/a &&
--
2.43.0-174-g055bb6e996
^ permalink raw reply related
* [ISSUE] `git push` keep asking for username when the global config already configured (wincred)
From: Andry @ 2023-12-21 16:16 UTC (permalink / raw)
To: Git
Hello Git,
Accidentally have found the issue when the Git is properly installed (git-scm.com) and configured over the global config under Window 8.
Btu if try to use the Cygwin (cygwin.com) installation for the Bash interpreter like this from the `myscript.bat`:
myscript.bat -> myscript.sh -> `git push ...`
Then the git asks for the username.
If directly run the command `git push ...`, then it works as expected without the username prompt.
The issue is around the HOME variable behind the Cygwin installation, when the Git thinks the configuration is in the Cygwin, instead of in the Windows users folder.
The workaround can be something like this:
```bash
# WORKAROUND:
# The `git push` asks for username under the bash shell call from the Windows cmd.exe script.
#
[[ -n "${COMSPEC+x}" ]] && unset HOME
```
>git --version
git version 2.43.0.windows.1
>winver
Version 6.2 (Build 9200)
^ permalink raw reply
* [PATCH 2/2] ref-filter: support filtering of operational refs
From: Karthik Nayak @ 2023-12-21 17:07 UTC (permalink / raw)
To: git; +Cc: gitster, ps, christian.couder, Karthik Nayak
In-Reply-To: <20231221170715.110565-1-karthik.188@gmail.com>
With the upcoming introduction of the reftable backend, it becomes ever
so important to provide the necessary tooling for printing all refs
associated with a repository.
While regular refs stored within the "refs/" namespace are currently
supported by multiple commands like git-for-each-ref(1),
git-show-ref(1). Neither support printing all the operational refs
within the repository.
This is crucial because with the reftable backend, all these refs will
also move to reftable. It would be necessary to identify all the refs
that are stored within the reftable since there is no easy way to do so
otherwise. This is because the reftable itself is a binary format and
all access will be via git. Unlike the filesystem backend, which allows
access directly via the filesystem.
This commit adds the necessary code to iterate over operational refs
present in a repository and provides a new filter flag
'FILTER_REFS_OPERATIONAL' to iterate over operational refs.
This flag can now be used to extend existing git commands to print
operational refs.
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
---
ref-filter.c | 12 ++++++++++++
ref-filter.h | 4 +++-
refs.c | 14 ++++++++++++++
refs.h | 3 +++
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/ref-filter.c b/ref-filter.c
index fdaabb5bb4..307a512c27 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -2756,6 +2756,10 @@ static int filter_ref_kind(struct ref_filter *filter, const char *refname)
filter->kind == FILTER_REFS_REMOTES ||
filter->kind == FILTER_REFS_TAGS)
return filter->kind;
+
+ if (filter->kind & FILTER_REFS_OPERATIONAL)
+ return filter->kind;
+
return ref_kind_from_refname(refname);
}
@@ -3032,6 +3036,14 @@ static int do_filter_refs(struct ref_filter *filter, unsigned int type, each_ref
if (!filter->kind)
die("filter_refs: invalid type");
else {
+ size_t i;
+ if (filter->kind & FILTER_REFS_OPERATIONAL) {
+ for (i = 0; i < operational_refs_max; i++) {
+ refs_single_ref(get_main_ref_store(the_repository),
+ operational_refs[i], fn, cb_data);
+ }
+ }
+
/*
* For common cases where we need only branches or remotes or tags,
* we only iterate through those refs. If a mix of refs is needed,
diff --git a/ref-filter.h b/ref-filter.h
index 0ce5af58ab..eec1d29514 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -23,7 +23,9 @@
#define FILTER_REFS_ALL (FILTER_REFS_TAGS | FILTER_REFS_BRANCHES | \
FILTER_REFS_REMOTES | FILTER_REFS_OTHERS)
#define FILTER_REFS_DETACHED_HEAD 0x0020
-#define FILTER_REFS_KIND_MASK (FILTER_REFS_ALL | FILTER_REFS_DETACHED_HEAD)
+#define FILTER_REFS_OPERATIONAL 0x0040
+#define FILTER_REFS_KIND_MASK (FILTER_REFS_ALL | FILTER_REFS_DETACHED_HEAD | \
+ FILTER_REFS_OPERATIONAL)
struct atom_value;
struct ref_sorting;
diff --git a/refs.c b/refs.c
index cebc5458d3..70f6854301 100644
--- a/refs.c
+++ b/refs.c
@@ -82,6 +82,20 @@ static unsigned char refname_disposition[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 4, 4
};
+const char *operational_refs[] = {
+ "HEAD",
+ "ORIG_HEAD",
+ "REBASE_HEAD",
+ "REVERT_HEAD",
+ "CHERRY_PICK_HEAD",
+ "BISECT_HEAD",
+ "BISECT_EXPECTED_REV",
+ "NOTES_MERGE_PARTIAL",
+ "NOTES_MERGE_REF",
+};
+
+const int operational_refs_max = ARRAY_SIZE(operational_refs) - 1;
+
struct ref_namespace_info ref_namespace[] = {
[NAMESPACE_HEAD] = {
.ref = "HEAD",
diff --git a/refs.h b/refs.h
index e147f13a85..b01938a91a 100644
--- a/refs.h
+++ b/refs.h
@@ -15,6 +15,9 @@ int default_ref_storage_format(void);
int ref_storage_format_by_name(const char *name);
const char *ref_storage_format_to_name(int ref_storage_format);
+extern const char *operational_refs[];
+extern const int operational_refs_max;
+
/*
* Resolve a reference, recursively following symbolic refererences.
*
--
2.43.GIT
^ permalink raw reply related
* [PATCH 1/2] refs: introduce the `refs_single_ref` function
From: Karthik Nayak @ 2023-12-21 17:07 UTC (permalink / raw)
To: git; +Cc: gitster, ps, christian.couder, Karthik Nayak
In-Reply-To: <20231221170715.110565-1-karthik.188@gmail.com>
We currently provide the functionality to iterate over refs and call a
specific callback. This functionality currently supports iterating over
the entire "refs/*" space or directly the "HEAD" ref. This leaves
operational refs "ORIG_HEAD", "REBASE_HEAD" and so forth behind.
In the following commit, we introduce a mechanism to process all the
operational refs outside the "refs/*" space. To do this, we require a
function similar `refs_head_ref`, which can process a single specified
reference. This commit introduces `refs_single_ref` to fill in that gap.
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
---
refs.c | 12 +++++++++---
refs.h | 2 ++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index 59fea0d44b..cebc5458d3 100644
--- a/refs.c
+++ b/refs.c
@@ -1549,18 +1549,24 @@ const char *find_descendant_ref(const char *dirname,
return NULL;
}
-int refs_head_ref(struct ref_store *refs, each_ref_fn fn, void *cb_data)
+int refs_single_ref(struct ref_store *refs, const char *refname,
+ each_ref_fn fn, void *cb_data)
{
struct object_id oid;
int flag;
- if (refs_resolve_ref_unsafe(refs, "HEAD", RESOLVE_REF_READING,
+ if (refs_resolve_ref_unsafe(refs, refname, RESOLVE_REF_READING,
&oid, &flag))
- return fn("HEAD", &oid, flag, cb_data);
+ return fn(refname, &oid, flag, cb_data);
return 0;
}
+int refs_head_ref(struct ref_store *refs, each_ref_fn fn, void *cb_data)
+{
+ return refs_single_ref(refs, "HEAD", fn, cb_data);
+}
+
int head_ref(each_ref_fn fn, void *cb_data)
{
return refs_head_ref(get_main_ref_store(the_repository), fn, cb_data);
diff --git a/refs.h b/refs.h
index 4816e46846..e147f13a85 100644
--- a/refs.h
+++ b/refs.h
@@ -324,6 +324,8 @@ typedef int each_repo_ref_fn(struct repository *r,
* modifies the reference also returns a nonzero value to immediately
* stop the iteration. Returned references are sorted.
*/
+int refs_single_ref(struct ref_store *refs, const char *refname,
+ each_ref_fn fn, void *cb_data);
int refs_head_ref(struct ref_store *refs,
each_ref_fn fn, void *cb_data);
int refs_for_each_ref(struct ref_store *refs,
--
2.43.GIT
^ permalink raw reply related
* [RFC 0/2] Initial changes to support printing all refs
From: Karthik Nayak @ 2023-12-21 17:07 UTC (permalink / raw)
To: git; +Cc: gitster, ps, christian.couder, Karthik Nayak
With the upcoming introduction of the reftable backend, it becomes ever
so important to provide the necessary tooling for printing all refs
associated with a repository.
While regular refs stored within the "refs/" namespace are currently
supported by multiple commands like git-for-each-ref(1),
git-show-ref(1). Neither support printing all the operational refs
within the repository.
This is crucial because with the reftable backend, all these refs will
also move to reftable. It would be necessary to identify all the refs
that are stored within the reftable since there is no easy way to do so
otherwise. This is because the reftable itself is a binary format and
all access will be via git. Unlike the filesystem backend, which allows
access directly via the filesystem.
This patch series is an RFC to discuss the intent and direction to be
taken to implement tooling for printing all refs in a repository. The
patches in this series implement a rather simple way to do this, by
iterating over a static list of operational refs. The drawback of this
approach is that this could still miss refs in the reftable/files
backend which are not in "refs" namespace or part of the list. The
positive being that this is ref backend agnostic.
The alternate approach would be to patch this inside individual backends
respectively, in the reftable backend this is rather simple, since we
simply iterate over all refs and not filter for "refs" namespace. In the
files backend, this can be done in two ways:
1. static approach: similar to this patch series, the files backend
would iterate over a static list of operational refs apart from the
"refs" directory.
2. dynamic approach: iterate over all files in `.git` folder and print
any refs if encountered. This is rather tedious and error prone, since
any file could be mistaken for a reference if the content is reference
like.
Personally, I'm leaning towards implementing this functionality inside
individual backends respectively, because that would allow the reftable
backend to print all its refs while the current approach might miss some
refs. But with the files backend, it would be best to still use a static
list.
Over this, I'm also curious on what the mailing list thinks about
exposing this to the client side. Would an `--all` option for
git-for-each-ref(1) be sufficient?
Karthik Nayak (2):
refs: introduce the `refs_single_ref` function
ref-filter: support filtering of operational refs
ref-filter.c | 12 ++++++++++++
ref-filter.h | 4 +++-
refs.c | 26 +++++++++++++++++++++++---
refs.h | 5 +++++
4 files changed, 43 insertions(+), 4 deletions(-)
--
2.43.GIT
^ permalink raw reply
* Re: [PATCH/RFC] sparse-checkout: take care of "--end-of-options" in set/add
From: Junio C Hamano @ 2023-12-21 17:02 UTC (permalink / raw)
To: Jeff King; +Cc: Josh Steadmon, git
In-Reply-To: <20231221084011.GB545870@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Dec 20, 2023 at 06:46:51PM -0800, Junio C Hamano wrote:
>
>> Josh Steadmon <steadmon@google.com> writes:
>>
>> > I can confirm that this fixes an issue noticed by sparse-checkout users
>> > at $DAYJOB. Looks good to me. Thanks!
>>
>> Heh, there is another one that is not converted in the same file for
>> "check-rules" subcommand, so the posted patch is way incomplete, I
>> think.
>
> Yeah. I think it is in the same boat as the other two, in that I believe
> that the KEEP_UNKNOWN_OPT flag is counter-productive and should just be
> dropped.
If we dropped KEEP_UNKNOWN_OPT, however, the pattern that is
currently accepted will stop working, e.g.,
$ git sparse-checkout [add/set] --[no-]cone --foo bar
as we would barf with "--foo: unknown option", and the users who are
used to this sloppy command line parsing we had for the past few
years must now write "--end-of-options" before "--foo". After all,
the reason why the original authors of this code used KEEP_UNKNOWN
is likely to deal with path patterns that begin with dashes.
The patch in the message that started this thread may not be
correct, either, I am afraid. For either of these:
$ git sparse-checkout [add/set] --[no-]cone foo --end-of-options bar
$ git sparse-checkout [add/set] --[no-]cone --foo --end-of-options bar
we would see that "foo" (or "--foo") is not "--end-of-options", and
we end up using three patterns "foo" (or "--foo"),
"--end-of-options", and "bar", I suspect. I wonder if we should
notice the "foo" or "--foo" that were not understood and error out,
instead.
But after all, it is not absolutely necessary to notice and barf.
The ONLY practical use of the "--end-of-options" mechanism is to
allow us to write (this applies to any git subcommand):
#!/bin/sh
git cmd --hard --coded --options --end-of-options "$@"
in scripts to protect the intended operation from mistaking the
end-user input as options. And with a script written carefully to
do so, all the args that appear before "--end-of-options" would be
recognizable by the command line parser. On the other hand, such a
"notice and barf" would not help a script that is written without
"--end-of-options", when it is fed "$@" that happens to begin with
"--end-of-options". We would silently swallow "--end-of-options"
without any chance to notice the lack of "--end-of-options" in the
script. So I dunno.
Here is an additional test on top of [1/3]
<20231221065925.3234048-2-gitster@pobox.com>
that demonstrates and summarizes the idea.
t/t1090-sparse-checkout-scope.sh | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git c/t/t1090-sparse-checkout-scope.sh w/t/t1090-sparse-checkout-scope.sh
index 5b96716235..da9534d222 100755
--- c/t/t1090-sparse-checkout-scope.sh
+++ w/t/t1090-sparse-checkout-scope.sh
@@ -54,6 +54,40 @@ test_expect_success 'return to full checkout of main' '
test "$(cat b)" = "modified"
'
+test_expect_success 'sparse-checkout set command line parsing' '
+ # baseline
+ git sparse-checkout disable &&
+ git sparse-checkout set --no-cone "a*" &&
+ echo "a*" >expect &&
+ test_cmp .git/info/sparse-checkout expect &&
+
+ # unknown string that looks like a dashed option is
+ # taken as a mere pattern
+ git sparse-checkout disable &&
+ git sparse-checkout set --no-cone --foo "a*" &&
+ test_write_lines "--foo" "a*" >expect &&
+ test_cmp .git/info/sparse-checkout expect &&
+
+ # --end-of-options can be used to protect parameters that
+ # potentially begin with dashes
+ set x --cone "a*" && shift &&
+ git sparse-checkout disable &&
+ git sparse-checkout set --no-cone --end-of-options "$@" &&
+ test_write_lines "$@" >expect &&
+ test_cmp .git/info/sparse-checkout expect &&
+
+ # but writing --end-of-options after what the command does not
+ # recognize is too late; it becomes one of the patterns, so
+ # that the end-user input that happens to be "--end-of-options"
+ # can be passed through. To be absoutely sure, you should write
+ # --end-of-options yourself before taking "$@" in.
+ set x --foo --end-of-options "a*" && shift &&
+ git sparse-checkout disable &&
+ git sparse-checkout set --no-cone "$@" &&
+ test_write_lines "$@" >expect &&
+ test_cmp .git/info/sparse-checkout expect
+'
+
test_expect_success 'skip-worktree on files outside sparse patterns' '
git sparse-checkout disable &&
git sparse-checkout set --no-cone "a*" &&
^ permalink raw reply related
* [PATCH v2 9/9] SubmittingPatches: hyphenate non-ASCII
From: Josh Soref via GitGitGadget @ 2023-12-21 16:41 UTC (permalink / raw)
To: git
Cc: Elijah Newren, René Scharfe, Phillip Wood, Josh Soref,
Josh Soref, Josh Soref
In-Reply-To: <pull.1623.v2.git.1703176865.gitgitgadget@gmail.com>
From: Josh Soref <jsoref@gmail.com>
Git documentation does this with the exception of ancient release notes.
Signed-off-by: Josh Soref <jsoref@gmail.com>
---
Documentation/SubmittingPatches | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index cb0dcce6a17..9283eb0ef71 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -699,7 +699,7 @@ message to an external program, and this is a handy way to drive
`git am`. However, if the message is MIME encoded, what is
piped into the program is the representation you see in your
`*Article*` buffer after unwrapping MIME. This is often not what
-you would want for two reasons. It tends to screw up non ASCII
+you would want for two reasons. It tends to screw up non-ASCII
characters (most notably in people's names), and also
whitespaces (fatal in patches). Running "C-u g" to display the
message in raw form before using "|" to run the pipe can work
--
gitgitgadget
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox