* Re: Fix git-send-email.perl w.r.t. recent Getopt::Long update
From: Junio C Hamano @ 2023-11-27 0:58 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20231124103932.31ca7688@pc09>
"H.Merijn Brand" <linux@tux.freedom.nl> writes:
> From the Getopt::Long changes:
> ```
> Changes in version 2.55
> -----------------------
> * Fix long standing bug that duplicate options were not detected when
> the options differ in case while ignore_case is in effect.
> This will now yield a warning and become a fatal error in a future
> release.
> ```
>
> Current version is 2.57
This patch looks like duplicate of
https://lore.kernel.org/git/20231116193014.470420-1-tmz@pobox.com/
perhaps independently discovered and worked on. Thanks for caring.
One downside of unconditional upgrade of the call is, of course,
that it would no longer work for those with older Getopt::Long that
did not support the "!" suffix. Fortunately, Getopt::Long 2.33
started shipping with Perl 5.8.1 that is more than 20 years old, so
with the series we accepted, we also have a change to bump the
required version of Perl from 5.8.0 to 5.8.1 to make it clear that
it is deliberate that we drop the support for anything older at the
same time.
^ permalink raw reply
* Re: [PATCH 4/4] completion: avoid user confusion in non-cone mode
From: Junio C Hamano @ 2023-11-27 1:39 UTC (permalink / raw)
To: Elijah Newren; +Cc: Elijah Newren via GitGitGadget, git
In-Reply-To: <CABPp-BE73cDq-DBKzsw3R0awiKn5J5LCfdXRULHyPbrS9GEn4Q@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
>> > if [[ "$using_cone" == "true" ]]; then
>> > __gitcomp_directories
>>
>> Hmph, doesn't "Providing the files and directories currently present
>> is thus always wrong." apply equally to cone mode?
>
> Absolutely, it definitely applies to cone mode. We (mostly) fixed
> that a long time ago, making it not complete on the files &
> directories currently present. In particular, the
> __gitcomp_directories() function highlighted here completes on the
> output of `git ls-tree -z -d --name-only HEAD`.
Thanks; what I missed was exactly what __gitcomp_directories does
not do you explained above.
>> > + # 4. Provides no completions when run from a
>> > + # subdirectory of the repository root. (If we
>> > + # did provide file/directory completions, the
>> > + # user would just get a "please run from the
>> > + # toplevel directory" error message when they
>> > + # ran it. *Further*, if the user did rerun
>> > + # the command from the toplevel, the
>> > + # completions we previously provided would
>> > + # likely be wrong as they'd be relative to the
>> > + # subdirectory rather than the repository
>> > + # root. That could lead to users getting a
>> > + # nasty surprise based on trying to use a
>> > + # command we helped them create.)
>>
>> Hmph, would an obvious alternative to (1) check against the HEAD (or
>> the index) to see if the prefix string matches an entity at the
>> current directory level, and then (2) to prefix the result of the
>> previous step with "/$(git rev-parse --show-prefix)" work? That is
>> something like this:
>>
>> $ cd t
>> $ git sparse-checkout add help<TAB>
>> ->
>> $ git sparse-checkout add /t/helper/
>
> I thought bash-completion was only for completions, not for startings
> as well. Was I mistaken?
To my mind, the completion is what I as an end user get when I type
<TAB> to help me formulate input that is acceptable by the command.
As I said, I consider it a bug (or UI mistake) in the a command if
it pretends to work inside a subdirecctory but complains when it is
given a path relative to the current directory, so I'd rather prefer
the approach to "fix" the underlying command, but if that is too
much work or cannot be done for whatever reason, the second best
would be to turn whatever we can do to help the end-user input into
a form that is accepted by the command without changing what the
input means. If it takes more than "appending at the end", that is
fine, at least by me as an end user.
If you are saying "completion code can only append at the end
because we can only return strings to be appended, not the entire
strings, to the readline machinery, so mucking with the start of the
string is not doable", then sorry---I accept that what we cannot do
cannot be done, and in that case you are "not mistaken".
But from the existing use of COMPREPLY[], it didn't look that way
(it seems __gitcomp is equipped to take fixed prefix to all
candidates by passing it in $2 and used to complete names of
configuration variables in a section, but it seems to me that it can
be repurposed when prefixing "$(git rev-parse --show-prefix)" to a
given pathname relative to the $cwd). And if that can be done, then
you are "not mistaken", but merely being dogmatic and limiting what
your code can do yourself.
>> Another more fundamental approach to avoid "confusion" this bullet
>> item tries to side step might be to *fix* the command that gets
>> completed. As "git sparse-checkout --help" is marked as
>> EXPERIMENTAL in capital letters, we should be able to say "what was
>> traditionally known as 'add' is from now on called 'add-pattern' and
>> command line completion would not get in the way; the 'add'
>> subcommand now takes only literal paths, not patterns, that are
>> relative to the current directory" if we wanted to.
>
> That's interesting...but it opens up a new can of worms:
> * Would we also need both `set-patterns` and `set`, in addition to
> `add-patterns` and `add`?
If "set" has a similar UI issue that confuses end-users, then sure,
I do not see a reason why we want to leave it confusing---the
experimental labelling is to allow us to fix these warts more
easily, no?
> * In cone mode, the paths passed are literal directories (and only
> directories; no individual files), but the thing added is a
> telescoping "cone" of leading directories as well. Does this make it
> potentially confusing to users to say that `add` only takes literal
> paths?
I do not know.
> * In cone mode (the default), should `add-patterns` just be an
> error, since no pattern specification is allowed?
I do not really care. "add-patterns" is a potential tool you can
use to reduce friction while fixing the UI warts in an experimental
command.
> * In the git-sparse-checkout manual, for performance reasons, we
> recommend users _not_ specify individual paths in non-cone mode.
> Would our recommendation then be to just not use `add` or `set` and
> only use `add-patterns` and `set-patterns`?
Very likely. If the desired behaviour from the command can only be
had by castrating features, then such a recommendation would not
mean much to end-users anyway, though.
> If so, what have we
> accomplished by adding the new names?
It is valuable for those who do need to go against recommendation
(because the recommendation robs usability from them way too much),
will have much less confusing and working completion when they use
'add' or 'set', no?
> Maybe I'm missing something about your suggestion, but this seems much
> more complex than the simple solution we implemented in bb8b5e9a90d
> ("sparse-checkout: pay attention to prefix for {set, add}",
> 2022-02-19) for the !core_sparse_checkout_cone case.
Oh, if we do honor the $(git rev-parse --show-prefix), then that
changes the equation somewhat. I got an impression from your log
message or cover letter that it wasn't the case, and that was where
the "if the command is so broken, then completion can add it for the
user" and "if the command is so broken, then fix it to take relative
paths" came from.
^ permalink raw reply
* Re: [PATCH 2/2] checkout: forbid "-B <branch>" from touching a branch used elsewhere
From: Junio C Hamano @ 2023-11-27 1:51 UTC (permalink / raw)
To: Phillip Wood; +Cc: Willem Verstraeten, git
In-Reply-To: <bf848477-b4dd-49d3-8e4b-de0fc3948570@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
>> diff --git a/builtin/checkout.c b/builtin/checkout.c
>> index b4ab972c5a..8a8ad23e98 100644
>> --- a/builtin/checkout.c
>> +++ b/builtin/checkout.c
>> @@ -1600,6 +1600,13 @@ static int checkout_branch(struct checkout_opts *opts,
>> if (new_branch_info->path && !opts->force_detach && !opts->new_branch)
>> die_if_switching_to_a_branch_in_use(opts, new_branch_info->path);
>> + /* "git checkout -B <branch>" */
>> + if (opts->new_branch_force) {
>> + char *full_ref = xstrfmt("refs/heads/%s", opts->new_branch);
>> + die_if_switching_to_a_branch_in_use(opts, full_ref);
>> + free(full_ref);
>
> At the moment this is academic as neither of the test scripts changed
> by this patch are leak free and so I don't think we need to worry
> about it but it raises an interesting question about how we should
> handle memory leaks when dying. Leaving the leak when dying means that
> a test script that tests an expected failure will never be leak free
> but using UNLEAK() would mean we miss a leak being introduced in the
> successful case should the call to "free()" ever be removed.
Is there a leak here? The piece of memory is pointed at by an on-stack
variable full_ref when leak sanitizer starts scanning the heap and
the stack just before the process exits due to die, so I do not see
a reason to worry about this particular variable over all the other
on stack variables we accumulated before the control reached this
point of the code.
Are you worried about optimizing compilers that behave more cleverly
than their own good to somehow lose the on-stack reference to
full_ref while calling die_if_switching_to_a_branch_in_use()? We
might need to squelch them with UNLEAK() but that does not mean we
have to remove the free() we see above, and I suspect a more
productive use of our time to solve that issue is ensure that our
leak-sanitizing build will not triger such an unwanted optimization
anyway.
Thanks.
^ permalink raw reply
* Re: Fix git-send-email.perl w.r.t. recent Getopt::Long update
From: H.Merijn Brand @ 2023-11-27 8:38 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <xmqqzfz03tbn.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]
On Mon, 27 Nov 2023 09:58:52 +0900, Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <linux@tux.freedom.nl> writes:
>
> > From the Getopt::Long changes:
> > ```
> > Changes in version 2.55
> > -----------------------
> > * Fix long standing bug that duplicate options were not detected when
> > the options differ in case while ignore_case is in effect.
> > This will now yield a warning and become a fatal error in a future
> > release.
> > ```
> >
> > Current version is 2.57
>
> This patch looks like duplicate of
>
> https://lore.kernel.org/git/20231116193014.470420-1-tmz@pobox.com/
>
> perhaps independently discovered and worked on. Thanks for caring.
>
> One downside of unconditional upgrade of the call is, of course,
> that it would no longer work for those with older Getopt::Long that
> did not support the "!" suffix. Fortunately, Getopt::Long 2.33
> started shipping with Perl 5.8.1 that is more than 20 years old, so
> with the series we accepted, we also have a change to bump the
> required version of Perl from 5.8.0 to 5.8.1 to make it clear that
> it is deliberate that we drop the support for anything older at the
> same time.
The is a no-issue ...
Just the 'use Getopt::Long' is enough to guarantee a working version:
The '!' was already implemented in version 2.10 (April 1997):
--8<---
=item !
Option does not take an argument and may be negated, i.e. prefixed by
"no". E.g. "foo!" will allow B<--foo> (with value 1) and B<-nofoo>
(with value 0).
The option variable will be set to 1, or 0 if negated.
-->8---
Looking at the ChangeLog, a reliable behavior of '!' was available
since version 2.22 (march 2000):
--8<---
Changes in version 2.22
-----------------------
* Fixes a bug in the combination of aliases and negation.
Old: "foo|bar!" allowed negation on foo, but not on bar.
New: "foo|bar!" allows negation on foo and bar.
Caveat: "foo|f!", with bundling, issues the warning that negation on
a short option is ignored. To obtain the desired behaviour, use
"foo!" => \$opt_foo, "f" => \$opt_foo
or
"foo|f" => \$opt_foo, "nofoo" => sub { $opt_foo = 0 }
Remember that this is _only_ required when bundling is in effect.
-->8---
--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* --end-of-options inconsistently available?!
From: Sven Strickroth @ 2023-11-27 11:22 UTC (permalink / raw)
To: git
Hi,
gitcli(7) states:
> Because -- disambiguates revisions and paths in some commands, it cannot be used for those commands to separate options and revisions. You can use --end-of-options for this (it also works for commands that do not distinguish between revisions in paths, in which case it is simply an alias for --).
However, when I use this for certain commands it fails:
$ git reset --end-of-options HEAD --
fatal: option '--end-of-options' must come before non-option arguments
$ git rev-parse --symbolic-full-name --end-of-options master
--end-of-options
refs/heads/master
Here, the output also contains "--end-of-options" as if it is a
reference (same for "--")
$ git checkout -f --end-of-options HEAD~1 -- afile.txt
fatal: only one reference expected, 2 given.
Best,
Sven
^ permalink raw reply
* Re: [PATCH] column: release strbuf and string_list after use
From: Junio C Hamano @ 2023-11-27 12:04 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List
In-Reply-To: <f087137d-a5aa-487e-a1cb-0ad7117b38ed@web.de>
René Scharfe <l.s.r@web.de> writes:
> Releasing strbuf and string_list just before exiting is not strictly
> necessary, but it gets rid of false positives reported by leak checkers,
> which can then be more easily used to show that the column-printing
> machinery behind print_columns() are free of leaks.
Thanks for being careful. Will queue.
^ permalink raw reply
* Re: [PATCH] i18n: factorize even more 'incompatible options' messages
From: Junio C Hamano @ 2023-11-27 13:11 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Jean-Noël Avila
In-Reply-To: <e6eb12e4-bb63-473c-9c2f-965a4d5981ad@web.de>
René Scharfe <l.s.r@web.de> writes:
> Continue the work of 12909b6b8a (i18n: turn "options are incompatible"
> into "cannot be used together", 2022-01-05) and a699367bb8 (i18n:
> factorize more 'incompatible options' messages, 2022-01-31) to use the
> same parameterized error message for reporting incompatible command line
> options. This reduces the number of strings to translate and makes the
> UI slightly more consistent.
Will queue. Thanks.
^ permalink raw reply
* Re: [PATCH] i18n: factorize even more 'incompatible options' messages
From: Junio C Hamano @ 2023-11-27 13:12 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Jean-Noël Avila
In-Reply-To: <e6eb12e4-bb63-473c-9c2f-965a4d5981ad@web.de>
René Scharfe <l.s.r@web.de> writes:
> Continue the work of 12909b6b8a (i18n: turn "options are incompatible"
> into "cannot be used together", 2022-01-05) and a699367bb8 (i18n:
> factorize more 'incompatible options' messages, 2022-01-31) to use the
> same parameterized error message for reporting incompatible command line
> options. This reduces the number of strings to translate and makes the
> UI slightly more consistent.
Will queue. Thanks.
^ permalink raw reply
* Re: [PATCH] remote-curl: avoid hang if curl asks for more data after eof
From: Jiří Hruška @ 2023-11-27 13:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Tan, git, Jeff King
In-Reply-To: <CAGE_+C7h6HOh+ptdhwJ3MNn5HWFoc1WF-foLRrew6FJEo_yupg@mail.gmail.com>
I have discussed this with Daniel Stenberg himself in this thread:
https://curl.se/mail/lib-2023-11/0017.html
The summary is:
- It was never intended/expected that CURLOPT_READFUNCTION would be called
more after already returning EOF once. libcurl has been modified to never
do this anymore (in master, to be released in what comes after 8.4.0).
- The problem has been tracked down to a particular case that could reproduce
only if using HTTP/2 and only in cURL versions 7.84.0 – 8.1.2 (inclusive,
roughly between June 2022 and July 2023). The same misbehavior is still
technically possible in newer versions, but not happening in practice.
Therefore, I believe nothing strongly _needs_ to be done on the Git side.
^ permalink raw reply
* Re: [PATCH v2 5/5] http: reset CURLOPT_POSTFIELDSIZE_LARGE between requests
From: Jiří Hruška @ 2023-11-27 13:21 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Jeff King, Jonathan Tan, Junio C Hamano
In-Reply-To: <ZVRovA9OSfY5odhy@tanuki>
> It feels quite easy for this list to grow stale whenever we start to set
> a new option somewhere else. Is there a specific reason why we can't
> instead use `curl_easy_reset()` here?
Good point, makes sense. Thanks, Patrick, I will use that instead.
^ permalink raw reply
* Re: [PATCH v2 0/5] Avoid hang if curl needs eof twice + minor related improvements
From: Jiří Hruška @ 2023-11-27 13:39 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, Jeff King, Junio C Hamano
In-Reply-To: <20231115232824.2507648-1-jonathantanmy@google.com>
> I've already reviewed 1/5 so I'll summarize what I think of the rest.
Thank you for your time looking at everything, Jonathan.
I'm sorry for the delay in my reply, I was away for a while and also trying
to get clarity from the cURL side, summarized in [1].
[1] https://lore.kernel.org/git/CAGE_+C5u9H8m5faK1vXKk6QTyjcHgKHqxOZy5ptzsYbF_0yrCQ@mail.gmail.com/
Most importantly, the bug has been apparently in libcurl only for ~1 year and
it can no longer manifest for a few months. Therefore, the main point of my
changes is a bit moot and we might reconsider what is useful and what is not.
> I'm a bit reluctant to include 2/5 and 4/5.
> I think 3/5 [...], part of 4/5 [...] and 5/5 have significant benefit and
> should be included, though.
Fair enough. I will update everything based on your and other's comments and
my new learnings, then the final decision can be made about each part.
^ permalink raw reply
* What's cooking in git.git (Nov 2023, #09; Mon, 27)
From: Junio C Hamano @ 2023-11-27 14:24 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
As I mentioned earlier, I'll be offline for a week or two, during
which time there will little movement in my repositories. The next
cycle should start soon after that.
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[New Topics]
* ad/merge-file-diff-algo (2023-11-22) 1 commit
- merge-file: add --diff-algorithm option
"git merge-file" learned to take the "--diff-algorithm" option to
use algorithm different from the default "myers" diff.
Will merge to 'next'?
source: <pull.1606.v2.git.git.1700507932937.gitgitgadget@gmail.com>
* ak/p4-initial-empty-commits (2023-11-23) 1 commit
- git-p4: fix fast import when empty commit is first
Expecting a reroll.
source: <pull.1609.git.git.1700639764041.gitgitgadget@gmail.com>
* jc/checkout-B-branch-in-use (2023-11-23) 2 commits
- checkout: forbid "-B <branch>" from touching a branch used elsewhere
- checkout: refactor die_if_checked_out() caller
"git checkout -B <branch> [<start-point>]" allowed a branch that is
in use in another worktree to be updated and checked out, which
might be a bit unexpected. The rule has been tightened, which is a
breaking change. "--ignore-other-worktrees" option is required to
unbreak you, if you are used to the current behaviour that "-B"
overrides the safety.
Needs review and documentation updates.
source: <xmqqjzq9cl70.fsf@gitster.g>
* jh/trace2-redact-auth (2023-11-23) 4 commits
- t0212: test URL redacting in EVENT format
- t0211: test URL redacting in PERF format
- trace2: redact passwords from https:// URLs by default
- trace2: fix signature of trace2_def_param() macro
trace2 streams used to record the URLs that potentially embed
authentication material, which has been corrected.
Will merge to 'next'.
source: <pull.1616.git.1700680717.gitgitgadget@gmail.com>
* ps/commit-graph-less-paranoid (2023-11-26) 1 commit
- commit-graph: disable GIT_COMMIT_GRAPH_PARANOIA by default
Earlier we stopped relying on commit-graph that (still) records
information about commits that are lost from the object store,
which has negative performance implications. The default has been
flipped to disable this pessimization.
Will merge to 'next'.
source: <17e08289cd59d20de0de9b4e18f5e6bf77987351.1700823746.git.ps@pks.im>
* ps/reftable-fixes (2023-11-22) 8 commits
- reftable/stack: fix stale lock when dying
- reftable/merged: reuse buffer to compute record keys
- reftable/stack: reuse buffers when reloading stack
- reftable/stack: perform auto-compaction with transactional interface
- reftable/stack: verify that `reftable_stack_add()` uses auto-compaction
- reftable: handle interrupted writes
- reftable: handle interrupted reads
- reftable: wrap EXPECT macros in do/while
Bunch of small fix-ups to the reftable code.
Needs review.
source: <cover.1700549493.git.ps@pks.im>
* en/complete-sparse-checkout (2023-11-27) 4 commits
- completion: avoid user confusion in non-cone mode
- completion: avoid misleading completions in cone mode
- completion: fix logic for determining whether cone mode is active
- completion: squelch stray errors in sparse-checkout completion
source: <pull.1349.v2.git.1700985086.gitgitgadget@gmail.com>
* jb/reflog-expire-delete-dry-run-options (2023-11-26) 1 commit
- builtin/reflog.c: fix dry-run option short name
source: <20231126000514.85509-1-josh@brob.st>
* jc/orphan-unborn (2023-11-24) 2 commits
- orphan/unborn: fix use of 'orphan' in end-user facing messages
- orphan/unborn: add to the glossary and use them consistently
source: <xmqq4jhb977x.fsf@gitster.g>
* rs/column-leakfix (2023-11-27) 1 commit
- column: release strbuf and string_list after use
source: <f087137d-a5aa-487e-a1cb-0ad7117b38ed@web.de>
* rs/i18n-cannot-be-used-together (2023-11-27) 1 commit
- i18n: factorize even more 'incompatible options' messages
source: <e6eb12e4-bb63-473c-9c2f-965a4d5981ad@web.de>
--------------------------------------------------
[Stalled]
* pw/rebase-sigint (2023-09-07) 1 commit
- rebase -i: ignore signals when forking subprocesses
If the commit log editor or other external programs (spawned via
"exec" insn in the todo list) receive internactive signal during
"git rebase -i", it caused not just the spawned program but the
"Git" process that spawned them, which is often not what the end
user intended. "git" learned to ignore SIGINT and SIGQUIT while
waiting for these subprocesses.
Expecting a reroll.
cf. <12c956ea-330d-4441-937f-7885ab519e26@gmail.com>
source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit
- cherry-pick: refuse cherry-pick sequence if index is dirty
"git cherry-pick A" that replays a single commit stopped before
clobbering local modification, but "git cherry-pick A..B" did not,
which has been corrected.
Expecting a reroll.
cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>
source: <pull.1535.v2.git.1685264889088.gitgitgadget@gmail.com>
* jc/diff-cached-fsmonitor-fix (2023-09-15) 3 commits
- diff-lib: fix check_removed() when fsmonitor is active
- Merge branch 'jc/fake-lstat' into jc/diff-cached-fsmonitor-fix
- Merge branch 'js/diff-cached-fsmonitor-fix' into jc/diff-cached-fsmonitor-fix
(this branch uses jc/fake-lstat.)
The optimization based on fsmonitor in the "diff --cached"
codepath is resurrected with the "fake-lstat" introduced earlier.
It is unknown if the optimization is worth resurrecting, but in case...
source: <xmqqr0n0h0tw.fsf@gitster.g>
--------------------------------------------------
[Cooking]
* ac/fuzz-show-date (2023-11-20) 1 commit
- fuzz: add new oss-fuzz fuzzer for date.c / date.h
Subject approxidate() and show_date() macchinery to OSS-Fuzz.
Will merge to 'next'?
source: <pull.1612.v4.git.1700243267653.gitgitgadget@gmail.com>
* js/packfile-h-typofix (2023-11-20) 1 commit
- packfile.c: fix a typo in `each_file_in_pack_dir_fn()`'s declaration
Typofix.
Will merge to 'next'.
source: <pull.1614.git.1700226915859.gitgitgadget@gmail.com>
* jw/builtin-objectmode-attr (2023-11-16) 2 commits
- SQUASH???
- attr: add builtin objectmode values support
The builtin_objectmode attribute is populated for each path
without adding anything in .gitattributes files, which would be
useful in magic pathspec, e.g., ":(attr:builtin_objectmode=100755)"
to limit to executables.
source: <20231116054437.2343549-1-jojwang@google.com>
* ps/ref-deletion-updates (2023-11-17) 4 commits
- refs: remove `delete_refs` callback from backends
- refs: deduplicate code to delete references
- refs/files: use transactions to delete references
- t5510: ensure that the packed-refs file needs locking
Simplify API implementation to delete references by eliminating
duplication.
Will merge to 'next'.
source: <cover.1699951815.git.ps@pks.im>
* tz/send-email-negatable-options (2023-11-17) 2 commits
(merged to 'next' on 2023-11-17 at f09e533e43)
+ send-email: avoid duplicate specification warnings
+ perl: bump the required Perl version to 5.8.1 from 5.8.0
Newer versions of Getopt::Long started giving warnings against our
(ab)use of it in "git send-email". Bump the minimum version
requirement for Perl to 5.8.1 (from September 2002) to allow
simplifying our implementation.
Will merge to 'master'.
source: <20231116193014.470420-1-tmz@pobox.com>
* js/ci-discard-prove-state (2023-11-14) 1 commit
(merged to 'next' on 2023-11-14 at fade3ba143)
+ ci: avoid running the test suite _twice_
(this branch uses ps/ci-gitlab.)
The way CI testing used "prove" could lead to running the test
suite twice needlessly, which has been corrected.
Will merge to 'master'.
source: <pull.1613.git.1699894837844.gitgitgadget@gmail.com>
* jk/chunk-bounds-more (2023-11-09) 9 commits
(merged to 'next' on 2023-11-13 at 3df4b18bea)
+ commit-graph: mark chunk error messages for translation
+ commit-graph: drop verify_commit_graph_lite()
+ commit-graph: check order while reading fanout chunk
+ commit-graph: use fanout value for graph size
+ commit-graph: abort as soon as we see a bogus chunk
+ commit-graph: clarify missing-chunk error messages
+ commit-graph: drop redundant call to "lite" verification
+ midx: check consistency of fanout table
+ commit-graph: handle overflow in chunk_size checks
(this branch is used by tb/pair-chunk-expect.)
Code clean-up for jk/chunk-bounds topic.
Will merge to 'master'.
source: <20231109070310.GA2697602@coredump.intra.peff.net>
* ps/httpd-tests-on-nixos (2023-11-11) 3 commits
(merged to 'next' on 2023-11-13 at 81bd6f5334)
+ t9164: fix inability to find basename(1) in Subversion hooks
+ t/lib-httpd: stop using legacy crypt(3) for authentication
+ t/lib-httpd: dynamically detect httpd and modules path
Portability tweak.
Will merge to 'master'.
source: <cover.1699596457.git.ps@pks.im>
* ss/format-patch-use-encode-headers-for-cover-letter (2023-11-10) 1 commit
(merged to 'next' on 2023-11-14 at 1a4bd59e15)
+ format-patch: fix ignored encode_email_headers for cover letter
"git format-patch --encode-email-headers" ignored the option when
preparing the cover letter, which has been corrected.
Will merge to 'master'.
source: <20231109111950.387219-1-contact@emersion.fr>
* ps/ban-a-or-o-operator-with-test (2023-11-11) 4 commits
(merged to 'next' on 2023-11-14 at d84471baab)
+ Makefile: stop using `test -o` when unlinking duplicate executables
+ contrib/subtree: convert subtree type check to use case statement
+ contrib/subtree: stop using `-o` to test for number of args
+ global: convert trivial usages of `test <expr> -a/-o <expr>`
Test and shell scripts clean-up.
Will merge to 'master'.
source: <cover.1699609940.git.ps@pks.im>
* ak/rebase-autosquash (2023-11-16) 3 commits
(merged to 'next' on 2023-11-17 at 3ed6e79445)
+ rebase: rewrite --(no-)autosquash documentation
+ rebase: support --autosquash without -i
+ rebase: fully ignore rebase.autoSquash without -i
"git rebase --autosquash" is now enabled for non-interactive rebase,
but it is still incompatible with the apply backend.
Will merge to 'master'.
source: <20231114214339.10925-1-andy.koppe@gmail.com>
* vd/for-each-ref-unsorted-optimization (2023-11-16) 10 commits
(merged to 'next' on 2023-11-17 at ff99420bf6)
+ t/perf: add perf tests for for-each-ref
+ ref-filter.c: use peeled tag for '*' format fields
+ for-each-ref: clean up documentation of --format
+ ref-filter.c: filter & format refs in the same callback
+ ref-filter.c: refactor to create common helper functions
+ ref-filter.c: rename 'ref_filter_handler()' to 'filter_one()'
+ ref-filter.h: add functions for filter/format & format-only
+ ref-filter.h: move contains caches into filter
+ ref-filter.h: add max_count and omit_empty to ref_format
+ ref-filter.c: really don't sort when using --no-sort
"git for-each-ref --no-sort" still sorted the refs alphabetically
which paid non-trivial cost. It has been redefined to show output
in an unspecified order, to allow certain optimizations to take
advantage of.
Will merge to 'master'.
source: <pull.1609.v2.git.1699991638.gitgitgadget@gmail.com>
* jw/git-add-attr-pathspec (2023-11-04) 1 commit
(merged to 'next' on 2023-11-13 at b61be94e4d)
+ attr: enable attr pathspec magic for git-add and git-stash
"git add" and "git stash" learned to support the ":(attr:...)"
magic pathspec.
Will merge to 'master'.
source: <20231103163449.1578841-1-jojwang@google.com>
* ps/ci-gitlab (2023-11-09) 8 commits
(merged to 'next' on 2023-11-10 at ea7ed67945)
+ ci: add support for GitLab CI
+ ci: install test dependencies for linux-musl
+ ci: squelch warnings when testing with unusable Git repo
+ ci: unify setup of some environment variables
+ ci: split out logic to set up failed test artifacts
+ ci: group installation of Docker dependencies
+ ci: make grouping setup more generic
+ ci: reorder definitions for grouping functions
(this branch is used by js/ci-discard-prove-state.)
Add support for GitLab CI.
Will merge to 'master'.
source: <cover.1699514143.git.ps@pks.im>
* ps/ref-tests-update (2023-11-03) 10 commits
(merged to 'next' on 2023-11-13 at dc26e55d6f)
+ t: mark several tests that assume the files backend with REFFILES
+ t7900: assert the absence of refs via git-for-each-ref(1)
+ t7300: assert exact states of repo
+ t4207: delete replace references via git-update-ref(1)
+ t1450: convert tests to remove worktrees via git-worktree(1)
+ t: convert tests to not access reflog via the filesystem
+ t: convert tests to not access symrefs via the filesystem
+ t: convert tests to not write references via the filesystem
+ t: allow skipping expected object ID in `ref-store update-ref`
+ Merge branch 'ps/show-ref' into ps/ref-tests-update
Update ref-related tests.
Will merge to 'master'.
source: <cover.1698914571.git.ps@pks.im>
* jx/fetch-atomic-error-message-fix (2023-10-19) 2 commits
- fetch: no redundant error message for atomic fetch
- t5574: test porcelain output of atomic fetch
"git fetch --atomic" issued an unnecessary empty error message,
which has been corrected.
Expecting an update.
cf. <ZTjQIrCgSANAT8wR@tanuki>
source: <ced46baeb1c18b416b4b4cc947f498bea2910b1b.1697725898.git.zhiyou.jx@alibaba-inc.com>
* js/bugreport-in-the-same-minute (2023-10-16) 1 commit
- bugreport: include +i in outfile suffix as needed
Instead of auto-generating a filename that is already in use for
output and fail the command, `git bugreport` learned to fuzz the
filename to avoid collisions with existing files.
Expecting a reroll.
cf. <ZTtZ5CbIGETy1ucV.jacob@initialcommit.io>
source: <20231016214045.146862-2-jacob@initialcommit.io>
* kh/t7900-cleanup (2023-10-17) 9 commits
- t7900: fix register dependency
- t7900: factor out packfile dependency
- t7900: fix `print-args` dependency
- t7900: fix `pfx` dependency
- t7900: factor out common schedule setup
- t7900: factor out inheritance test dependency
- t7900: create commit so that branch is born
- t7900: setup and tear down clones
- t7900: remove register dependency
Test clean-up.
Perhaps discard?
cf. <655ca147-c214-41be-919d-023c1b27b311@app.fastmail.com>
source: <cover.1697319294.git.code@khaugsbakk.name>
* tb/merge-tree-write-pack (2023-10-23) 5 commits
- builtin/merge-tree.c: implement support for `--write-pack`
- bulk-checkin: introduce `index_tree_bulk_checkin_incore()`
- bulk-checkin: introduce `index_blob_bulk_checkin_incore()`
- bulk-checkin: generify `stream_blob_to_pack()` for arbitrary types
- bulk-checkin: extract abstract `bulk_checkin_source`
"git merge-tree" learned "--write-pack" to record its result
without creating loose objects.
Broken when an object created during a merge is needed to continue merge
cf. <CABPp-BEfy9VOvimP9==ry_rZXu=metOQ8s=_-XiG_Pdx9c06Ww@mail.gmail.com>
source: <cover.1698101088.git.me@ttaylorr.com>
* tb/pair-chunk-expect (2023-11-10) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` chunk with `pair_chunk_expect()`
- commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
- commit-graph: read `GDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `CDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `OIDL` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
- Merge branch 'jk/chunk-bounds-more' into HEAD
(this branch uses jk/chunk-bounds-more.)
Further code clean-up.
Needs review.
source: <cover.1699569246.git.me@ttaylorr.com>
* tb/path-filter-fix (2023-10-18) 17 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
- commit-graph: ensure Bloom filters are read with consistent settings
- revision.c: consult Bloom filters for root commits
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Needs (hopefully final and quick) review.
source: <cover.1697653929.git.me@ttaylorr.com>
* cc/git-replay (2023-11-26) 14 commits
- replay: stop assuming replayed branches do not diverge
- replay: add --contained to rebase contained branches
- replay: add --advance or 'cherry-pick' mode
- replay: use standard revision ranges
- replay: make it a minimal server side command
- replay: remove HEAD related sanity check
- replay: remove progress and info output
- replay: add an important FIXME comment about gpg signing
- replay: change rev walking options
- replay: introduce pick_regular_commit()
- replay: die() instead of failing assert()
- replay: start using parse_options API
- replay: introduce new builtin
- t6429: remove switching aspects of fast-rebase
Introduce "git replay", a tool meant on the server side without
working tree to recreate a history.
Will merge to 'next'.
cf. <6bfe1541-54dd-ca6b-e930-94d3038060f1@gmx.de>
source: <20231124111044.3426007-1-christian.couder@gmail.com>
* ak/color-decorate-symbols (2023-10-23) 7 commits
- log: add color.decorate.pseudoref config variable
- refs: exempt pseudorefs from pattern prefixing
- refs: add pseudorefs array and iteration functions
- log: add color.decorate.ref config variable
- log: add color.decorate.symbol config variable
- log: use designated inits for decoration_colors
- config: restructure color.decorate documentation
A new config for coloring.
Needs review.
source: <20231023221143.72489-1-andy.koppe@gmail.com>
* js/update-urls-in-doc-and-comment (2023-11-26) 4 commits
- doc: refer to internet archive
- doc: update links for andre-simon.de
- doc: switch links to https
- doc: update links to current pages
Stale URLs have been updated to their current counterparts (or
archive.org) and HTTP links are replaced with working HTTPS links.
Will merge to 'next'.
source: <pull.1589.v3.git.1700796916.gitgitgadget@gmail.com>
* la/trailer-cleanups (2023-10-20) 3 commits
- trailer: use offsets for trailer_start/trailer_end
- trailer: find the end of the log message
- commit: ignore_non_trailer computes number of bytes to ignore
Code clean-up.
Comments?
source: <pull.1563.v5.git.1697828495.gitgitgadget@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Needs review.
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-10-04) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Needs review.
source: <cover.1696432593.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-10-04) 3 commits
- pkt-line: do not chomp newlines for sideband messages
- pkt-line: memorize sideband fragment in reader
- test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Needs review.
source: <cover.1696425168.git.zhiyou.jx@alibaba-inc.com>
* js/config-parse (2023-09-21) 5 commits
- config-parse: split library out of config.[c|h]
- config.c: accept config_parse_options in git_config_from_stdin
- config: report config parse errors using cb
- config: split do_event() into start and flush operations
- config: split out config_parse_options
The parsing routines for the configuration files have been split
into a separate file.
Needs review.
source: <cover.1695330852.git.steadmon@google.com>
* jc/fake-lstat (2023-09-15) 1 commit
- cache: add fake_lstat()
(this branch is used by jc/diff-cached-fsmonitor-fix.)
A new helper to let us pretend that we called lstat() when we know
our cache_entry is up-to-date via fsmonitor.
Needs review.
source: <xmqqcyykig1l.fsf@gitster.g>
* js/doc-unit-tests (2023-11-10) 3 commits
(merged to 'next' on 2023-11-10 at 7d00ffd06b)
+ ci: run unit tests in CI
+ unit tests: add TAP unit test framework
+ unit tests: add a project plan document
(this branch is used by js/doc-unit-tests-with-cmake.)
Process to add some form of low-level unit tests has started.
Will merge to 'master'.
source: <cover.1699555664.git.steadmon@google.com>
* js/doc-unit-tests-with-cmake (2023-11-10) 7 commits
(merged to 'next' on 2023-11-10 at b4503c9c8c)
+ cmake: handle also unit tests
+ cmake: use test names instead of full paths
+ cmake: fix typo in variable name
+ artifacts-tar: when including `.dll` files, don't forget the unit-tests
+ unit-tests: do show relative file paths
+ unit-tests: do not mistake `.pdb` files for being executable
+ cmake: also build unit tests
(this branch uses js/doc-unit-tests.)
Update the base topic to work with CMake builds.
Will merge to 'master'.
source: <pull.1579.v3.git.1695640836.gitgitgadget@gmail.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
* rj/status-bisect-while-rebase (2023-10-16) 1 commit
- status: fix branch shown when not only bisecting
"git status" is taught to show both the branch being bisected and
being rebased when both are in effect at the same time.
Needs review.
source: <2e24ca9b-9c5f-f4df-b9f8-6574a714dfb2@gmail.com>
--------------------------------------------------
[Discarded]
* jc/strbuf-comment-line-char (2023-11-01) 4 commits
. strbuf: move env-using functions to environment.c
. strbuf: make add_lines() public
. strbuf_add_commented_lines(): drop the comment_line_char parameter
. strbuf_commented_addf(): drop the comment_line_char parameter
Code simplification that goes directly against a past libification
topic. It is hard to judge because the "libification" is done
piecewise without seemingly clear design principle.
Will discard.
source: <cover.1698791220.git.jonathantanmy@google.com>
^ permalink raw reply
* Re: [PATCH] i18n: factorize even more 'incompatible options' messages
From: René Scharfe @ 2023-11-27 17:39 UTC (permalink / raw)
To: Eric Sunshine
Cc: Jean-Noël Avila, Patrick Steinhardt, Junio C Hamano,
Git List
In-Reply-To: <CAPig+cR5PKkyC24LkOU4+yzng1xeBOBbADTBHXH61xkAR7kymw@mail.gmail.com>
Am 26.11.23 um 18:49 schrieb Eric Sunshine:
> On Sun, Nov 26, 2023 at 6:57 AM René Scharfe <l.s.r@web.de> wrote:
>> Continue the work of 12909b6b8a (i18n: turn "options are incompatible"
>> into "cannot be used together", 2022-01-05) and a699367bb8 (i18n:
>> factorize more 'incompatible options' messages, 2022-01-31) to use the
>> same parameterized error message for reporting incompatible command line
>> options. This reduces the number of strings to translate and makes the
>> UI slightly more consistent.
>
> Thanks for tackling this.
>
> A couple additional instances recently slipped into `show-ref.c` which
> were caught during review[1,2] but nevertheless made it to
> "master"[3,4]. This patch, of course, doesn't need to address those,
> but if rerolling for some other reason, perhaps they can be included,
> as well(?).
>
> [1]: https://lore.kernel.org/git/CAPig+cSrp7vZuy7D_ENHKZKZzF4OSmCtfYNHPGMtS1Hj6gArDw@mail.gmail.com/
> [2]: https://lore.kernel.org/git/CAPig+cRTOMie0rUf=Mhbo9e2EXf-_2kQyMeqpB9OCRB1MZZ1rw@mail.gmail.com/
> [3]: 199970e72f (builtin/show-ref: ensure mutual exclusiveness of
> subcommands, 2023-10-31)
> [4]: 9080a7f178 (builtin/show-ref: add new mode to check for reference
> existence, 2023-10-31)
[4] changes the message added by [3], so that's one instance, right?
--- >8 ---
Subject: [PATCH] show-ref: use die_for_incompatible_opt3()
Use the standard message for reporting the use of multiple mutually
exclusive options by calling die_for_incompatible_opt3() instead of
rolling our own. This has the benefits of showing only the actually
given options, reducing the number of strings to translate and making
the UI slightly more consistent.
Adjust the test to no longer insist on a specific order of the
reported options, as this implementation detail does not affect the
usefulness of the error message.
Reported-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
---
builtin/show-ref.c | 6 +++---
t/t1403-show-ref.sh | 16 +++++++++-------
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/builtin/show-ref.c b/builtin/show-ref.c
index 7aac525a87..59d2291cbf 100644
--- a/builtin/show-ref.c
+++ b/builtin/show-ref.c
@@ -315,9 +315,9 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, show_ref_options,
show_ref_usage, 0);
- if ((!!exclude_existing_opts.enabled + !!verify + !!exists) > 1)
- die(_("only one of '%s', '%s' or '%s' can be given"),
- "--exclude-existing", "--verify", "--exists");
+ die_for_incompatible_opt3(exclude_existing_opts.enabled, "--exclude-existing",
+ verify, "--verify",
+ exists, "--exists");
if (exclude_existing_opts.enabled)
return cmd_show_ref__exclude_existing(&exclude_existing_opts);
diff --git a/t/t1403-show-ref.sh b/t/t1403-show-ref.sh
index b50ae6fcf1..d477689e33 100755
--- a/t/t1403-show-ref.sh
+++ b/t/t1403-show-ref.sh
@@ -197,18 +197,20 @@ test_expect_success 'show-ref --verify with dangling ref' '
'
test_expect_success 'show-ref sub-modes are mutually exclusive' '
- cat >expect <<-EOF &&
- fatal: only one of ${SQ}--exclude-existing${SQ}, ${SQ}--verify${SQ} or ${SQ}--exists${SQ} can be given
- EOF
-
test_must_fail git show-ref --verify --exclude-existing 2>err &&
- test_cmp expect err &&
+ grep "verify" err &&
+ grep "exclude-existing" err &&
+ grep "cannot be used together" err &&
test_must_fail git show-ref --verify --exists 2>err &&
- test_cmp expect err &&
+ grep "verify" err &&
+ grep "exists" err &&
+ grep "cannot be used together" err &&
test_must_fail git show-ref --exclude-existing --exists 2>err &&
- test_cmp expect err
+ grep "exclude-existing" err &&
+ grep "exists" err &&
+ grep "cannot be used together" err
'
test_expect_success '--exists with existing reference' '
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] i18n: factorize even more 'incompatible options' messages
From: Eric Sunshine @ 2023-11-27 17:48 UTC (permalink / raw)
To: René Scharfe
Cc: Jean-Noël Avila, Patrick Steinhardt, Junio C Hamano,
Git List
In-Reply-To: <d1f28272-635d-4638-b0f4-76d64013b0d5@web.de>
On Mon, Nov 27, 2023 at 12:39 PM René Scharfe <l.s.r@web.de> wrote:
> Am 26.11.23 um 18:49 schrieb Eric Sunshine:
> > A couple additional instances recently slipped into `show-ref.c` which
> > were caught during review[1,2] but nevertheless made it to
> > "master"[3,4]. This patch, of course, doesn't need to address those,
> > but if rerolling for some other reason, perhaps they can be included,
> > as well(?).
> >
> > [1]: https://lore.kernel.org/git/CAPig+cSrp7vZuy7D_ENHKZKZzF4OSmCtfYNHPGMtS1Hj6gArDw@mail.gmail.com/
> > [2]: https://lore.kernel.org/git/CAPig+cRTOMie0rUf=Mhbo9e2EXf-_2kQyMeqpB9OCRB1MZZ1rw@mail.gmail.com/
> > [3]: 199970e72f (builtin/show-ref: ensure mutual exclusiveness of
> > subcommands, 2023-10-31)
> > [4]: 9080a7f178 (builtin/show-ref: add new mode to check for reference
> > existence, 2023-10-31)
>
> [4] changes the message added by [3], so that's one instance, right?
Yes, correct. Sorry for misleadingly saying there were two new
messages; it's been a month since I looked at the patches closely, and
forgot that it was just the single message which had been modified by
the subsequent patch.
Thanks for taking care of this so quickly!
> --- >8 ---
> Subject: [PATCH] show-ref: use die_for_incompatible_opt3()
>
> Use the standard message for reporting the use of multiple mutually
> exclusive options by calling die_for_incompatible_opt3() instead of
> rolling our own. This has the benefits of showing only the actually
> given options, reducing the number of strings to translate and making
> the UI slightly more consistent.
>
> Adjust the test to no longer insist on a specific order of the
> reported options, as this implementation detail does not affect the
> usefulness of the error message.
>
> Signed-off-by: René Scharfe <l.s.r@web.de>
Apparently, I haven't been following along closely enough, thus wasn't
aware that we had the die_for_incompatible_opt*() family of functions.
Neat.
^ permalink raw reply
* Re: [PATCH v2 0/5] Avoid hang if curl needs eof twice + minor related improvements
From: Jonathan Tan @ 2023-11-27 18:26 UTC (permalink / raw)
To: Jiří Hruška; +Cc: Jonathan Tan, git, Jeff King, Junio C Hamano
In-Reply-To: <CAGE_+C4B=zjPqNV+fGt9gaA0O8qmqmK3CDh-eLBPmXx+ChzXAQ@mail.gmail.com>
Jiří Hruška <jirka@fud.cz> writes:
> > I've already reviewed 1/5 so I'll summarize what I think of the rest.
> Thank you for your time looking at everything, Jonathan.
>
> I'm sorry for the delay in my reply, I was away for a while and also trying
> to get clarity from the cURL side, summarized in [1].
>
> [1] https://lore.kernel.org/git/CAGE_+C5u9H8m5faK1vXKk6QTyjcHgKHqxOZy5ptzsYbF_0yrCQ@mail.gmail.com/
>
> Most importantly, the bug has been apparently in libcurl only for ~1 year and
> it can no longer manifest for a few months. Therefore, the main point of my
> changes is a bit moot and we might reconsider what is useful and what is not.
Thanks for following up with the Curl side. Even if the Curl bug is
fixed now, for what it's worth, I still think that it's worth including
this mitigation in Git.
^ permalink raw reply
* Re: [PATCH] setup: recognize bare repositories with packed-refs
From: Josh Steadmon @ 2023-11-27 19:42 UTC (permalink / raw)
To: Glen Choo; +Cc: Junio C Hamano, git, Adam Majer
In-Reply-To: <CA+we5Gqp2nhoXyqJKJiXQMDx-ZXcnNGHu3wnwERWREng2XHHuQ@mail.gmail.com>
On 2023.11.20 17:31, Glen Choo wrote:
> On Mon, Nov 20, 2023 at 7:24 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Adam Majer <adamm@zombino.com> writes:
> >
> > > In a garbage collected bare git repository, the refs/ subdirectory is
> > > empty. In use-cases when such a repository is directly added into
> > > another repository, it no longer is detected as valid.
> >
> > Josh & Glen [*], isn't this a layout that we explicitly discourage and
> > eventually plan to forbid anyway?
>
> If my recollection of [1] serves me correctly, we didn't come to a
> strong conclusion on whether or not to forbid bare repositories in the
> working tree, particularly because it would leave existing repos (like
> Git LFS) high and dry. Though personally, I'd be happy to see a
> version of Git that forbade bare repositories in the working tree.
>
> I don't really recall the bare repo tracing bits, so I'll leave that to Josh.
>
> [1] https://lore.kernel.org/git/kl6lsfqpygsj.fsf@chooglen-macbookpro.roam.corp.google.com/
Yeah, my understanding was that we don't want to forbid bare
repositories outright, which is why we have the config option to let
end-users choose what to do with them.
^ permalink raw reply
* Re: [PATCH] setup: recognize bare repositories with packed-refs
From: Josh Steadmon @ 2023-11-27 19:44 UTC (permalink / raw)
To: Adam Majer; +Cc: git
In-Reply-To: <20231117203253.21143-1-adamm@zombino.com>
On 2023.11.17 21:32, Adam Majer wrote:
> In a garbage collected bare git repository, the refs/ subdirectory is
> empty. In use-cases when such a repository is directly added into
> another repository, it no longer is detected as valid. Git doesn't
> preserve empty paths so refs/ subdirectory is not present. Simply
> creating an empty refs/ subdirectory fixes this problem.
>
> Looking more carefully, there are two backends to handle various refs in
> git -- the files backend that uses refs/ subdirectory and the
> packed-refs backend that uses packed-refs file. If references are not
> found in refs/ subdirectory (or directory doesn't exist), the
> packed-refs directory will be consulted. Garbage collected repository
> will have all its references in packed-refs file.
>
> To allow the use-case when packed-refs is the only source of refs and
> refs/ subdirectory is simply not present, augment 'is_git_directory()'
> setup function to look for packed-refs file as an alternative to refs/
> subdirectory.
>
> Signed-off-by: Adam Majer <adamm@zombino.com>
> ---
> setup.c | 10 +++++++---
> t/t6500-gc.sh | 8 ++++++++
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index fc592dc6dd..2a6dda6ae9 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -348,7 +348,7 @@ int get_common_dir_noenv(struct strbuf *sb, const char *gitdir)
> *
> * - either an objects/ directory _or_ the proper
> * GIT_OBJECT_DIRECTORY environment variable
> - * - a refs/ directory
> + * - a refs/ directory or packed-refs file
> * - either a HEAD symlink or a HEAD file that is formatted as
> * a proper "ref:", or a regular file HEAD that has a properly
> * formatted sha1 object name.
> @@ -384,8 +384,12 @@ int is_git_directory(const char *suspect)
>
> strbuf_setlen(&path, len);
> strbuf_addstr(&path, "/refs");
> - if (access(path.buf, X_OK))
> - goto done;
> + if (access(path.buf, X_OK)) {
> + strbuf_setlen(&path, len);
> + strbuf_addstr(&path, "/packed-refs");
> + if (access(path.buf, R_OK))
> + goto done;
> + }
>
> ret = 1;
> done:
> diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh
> index 18fe1c25e6..e81eb7d2ab 100755
> --- a/t/t6500-gc.sh
> +++ b/t/t6500-gc.sh
> @@ -214,6 +214,14 @@ test_expect_success 'gc.repackFilter launches repack with a filter' '
> grep -E "^trace: (built-in|exec|run_command): git repack .* --filter=blob:none ?.*" trace.out
> '
>
> +test_expect_success 'remove empty refs/ subdirectory' '
> + git -C bare.git cat-file -e 60dd8ad7d8ed49005c18b7ce9f5b7a45c28df814 &&
> + test_dir_is_empty bare.git/refs/heads &&
> + test_dir_is_empty bare.git/refs/tags &&
> + rm -r bare.git/refs &&
> + GIT_DIR="$PWD"/bare.git git -C bare.git cat-file -e 60dd8ad7d8ed49005c18b7ce9f5b7a45c28df814
> +'
> +
Two suggestions for the test here:
1) Can you give the test a more descriptive name, such as "GCed bare
repos still recognized"?
2) Can you add a check that bare.git/packed-refs exists?
Other than that, looks good to me.
Reviewed-by: Josh Steadmon <steadmon@google.com>
^ permalink raw reply
* Re: --end-of-options inconsistently available?!
From: Jeff King @ 2023-11-27 21:22 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git
In-Reply-To: <4d944fe3-d31d-4859-8ed2-6c1da64410fe@cs-ware.de>
On Mon, Nov 27, 2023 at 12:22:44PM +0100, Sven Strickroth wrote:
> Hi,
>
> gitcli(7) states:
> > Because -- disambiguates revisions and paths in some commands, it cannot be used for those commands to separate options and revisions. You can use --end-of-options for this (it also works for commands that do not distinguish between revisions in paths, in which case it is simply an alias for --).
>
> However, when I use this for certain commands it fails:
>
> $ git reset --end-of-options HEAD --
> fatal: option '--end-of-options' must come before non-option arguments
This one seems like a bug. Handling of --end-of-options usually happens
via the parse_options() API. But in this case, cmd_reset() calls it with
PARSE_OPT_KEEP_DASHDASH, which retains the --end-of-options marker. But
then the caller is not ready to deal with that string being left in
argv[0] (it is OK with "--", but not anything else).
So at first glance, it feels like parse-options should avoid leaving it
in place, like:
diff --git a/parse-options.c b/parse-options.c
index e0c94b0546..5c07ad47ec 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -931,7 +931,7 @@ enum parse_opt_result parse_options_step(struct parse_opt_ctx_t *ctx,
if (!arg[2] /* "--" */ ||
!strcmp(arg + 2, "end-of-options")) {
- if (!(ctx->flags & PARSE_OPT_KEEP_DASHDASH)) {
+ if (arg[2] || !(ctx->flags & PARSE_OPT_KEEP_DASHDASH)) {
ctx->argc--;
ctx->argv++;
}
But I think that confuses other callers. For example, t4202 fails
because we try (with a ref called refs/heads/--source) to run:
git log --end-of-options --source
expecting it it to be resolved as a ref. With the patch above, it gets
confused. So I think we may need to teach KEEP_DASHDASH callers to
handle end-of-options themselves. In the case of git-log, it is done by
the revision machinery, but reset doesn't use that.
So something like this works:
diff --git a/builtin/reset.c b/builtin/reset.c
index 4b018d20e3..a0d801179a 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -259,6 +259,9 @@ static void parse_args(struct pathspec *pathspec,
* At this point, argv points immediately after [-opts].
*/
+ if (argv[0] && !strcmp(argv[0], "--end-of-options"))
+ argv++;
+
if (argv[0]) {
if (!strcmp(argv[0], "--")) {
argv++; /* reset to HEAD, possibly with paths */
but it feels like a maintenance problem that we'd have to audit every
caller that uses KEEP_DASHDASH.
On the other hand, I do think the callers need to be a bit aware of the
issue to make things work seamlessly. In particular, this now does what
you'd expect:
git reset --end-of-options foo -- bar
But if we do this:
git reset --end-of-options --foo
it works if "--foo" can be resolved, but otherwise complains "option
'--foo' must come before non-option arguments", even if it exists as a
file! IOW, the do-what-I-mean handling of "--" is too picky; in
verify_filename() it complains about things that look like options, not
realizing we already made sure to avoid those.
OTOH that is also true of "git log --end-of-options --foo". And maybe
not that big a deal in practice. If you are truly being careful you'd
always do:
git log --end-of-options --foo -- --bar
anyway, which is unambiguous.
So I dunno. I'm not sure there's a central fix, and we may have to just
fix this spot and look for others.
> $ git rev-parse --symbolic-full-name --end-of-options master
> --end-of-options
> refs/heads/master
>
> Here, the output also contains "--end-of-options" as if it is a reference
> (same for "--")
This one is intentional. rev-parse in its default mode is not just
spitting out revisions, but also options that are meant to be passed
along to the revision machinery via other commands (like rev-list). So
for example:
$ git rev-parse --foo HEAD
--foo
564d0252ca632e0264ed670534a51d18a689ef5d
And it does understand end-of-options explicitly, so:
$ git rev-parse --end-of-options --foo --
--end-of-options
fatal: bad revision '--foo'
If you just want to parse a name robustly, use --verify.
> $ git checkout -f --end-of-options HEAD~1 -- afile.txt
> fatal: only one reference expected, 2 given.
I think this is the same KEEP_DASHDASH problem as with git-reset.
-Peff
^ permalink raw reply related
* Re: [PATCH 2/2] checkout: forbid "-B <branch>" from touching a branch used elsewhere
From: Jeff King @ 2023-11-27 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Phillip Wood, Willem Verstraeten, git
In-Reply-To: <xmqqwmu42ccb.fsf@gitster.g>
On Mon, Nov 27, 2023 at 10:51:00AM +0900, Junio C Hamano wrote:
> >> + if (opts->new_branch_force) {
> >> + char *full_ref = xstrfmt("refs/heads/%s", opts->new_branch);
> >> + die_if_switching_to_a_branch_in_use(opts, full_ref);
> >> + free(full_ref);
> >
> > At the moment this is academic as neither of the test scripts changed
> > by this patch are leak free and so I don't think we need to worry
> > about it but it raises an interesting question about how we should
> > handle memory leaks when dying. Leaving the leak when dying means that
> > a test script that tests an expected failure will never be leak free
> > but using UNLEAK() would mean we miss a leak being introduced in the
> > successful case should the call to "free()" ever be removed.
>
> Is there a leak here? The piece of memory is pointed at by an on-stack
> variable full_ref when leak sanitizer starts scanning the heap and
> the stack just before the process exits due to die, so I do not see
> a reason to worry about this particular variable over all the other
> on stack variables we accumulated before the control reached this
> point of the code.
Right, I think the only reasonable approach here is to not consider this
a leak. We've discussed this in the past. Here's a link into a relevant
thread for reference, but I don't think it's really worth anybody's
time to re-visit:
https://lore.kernel.org/git/Y0+i1G5ybdhUGph2@coredump.intra.peff.net/
> Are you worried about optimizing compilers that behave more cleverly
> than their own good to somehow lose the on-stack reference to
> full_ref while calling die_if_switching_to_a_branch_in_use()? We
> might need to squelch them with UNLEAK() but that does not mean we
> have to remove the free() we see above, and I suspect a more
> productive use of our time to solve that issue is ensure that our
> leak-sanitizing build will not triger such an unwanted optimization
> anyway.
We did have that problem, but it should no longer be the case after
d3775de074 (Makefile: force -O0 when compiling with SANITIZE=leak,
2022-10-18). If that is not sufficient for some compiler/code combo, I'd
be interested to hear about it.
-Peff
^ permalink raw reply
* Re: Fix git-send-email.perl w.r.t. recent Getopt::Long update
From: Jeff King @ 2023-11-27 21:38 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Bagas Sanjaya, Git Mailing List
In-Reply-To: <20231125104211.5b7fe0be@pc09>
On Sat, Nov 25, 2023 at 10:45:22AM +0100, H.Merijn Brand wrote:
> As I am used to PR's by now on all OSS projects I am involved in, or
> use git commits or merges directly on the repo, I *never* use
> format-patch and/or send-email.
>
> These docs - yes I read them - do not offer a concise cut-n-paste
> example for people like me. In order to have my relative simple patch
> submitted (I already had the PR ready, but that came with a huge
> warning that PR's are not accepted) I did it the way I did it. Now I
> need to read and learn two new commands> I don't think that is very
> user-friendly, but that might be just me.
These days you can use GitGitGadget to submit a PR to the mailing list:
https://gitgitgadget.github.io/
The PR template mentions this, as well as the "about" text for git/git,
but I won't be surprised if there are other spots that should be updated
to mention it. If you found a message that would benefit from mentioning
it, let us know so we can update it.
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH 2/4] trace2: redact passwords from https:// URLs by default
From: Jeff King @ 2023-11-27 21:50 UTC (permalink / raw)
To: Elijah Newren
Cc: Johannes Schindelin via GitGitGadget, git, Johannes Schindelin
In-Reply-To: <CABPp-BELjVqVEB3oVx3fMzmvNfE1f7muLR_2k912_C+SaQtZtg@mail.gmail.com>
On Thu, Nov 23, 2023 at 10:59:20AM -0800, Elijah Newren wrote:
> > Let's at least avoid logging such secrets via Trace2, much like we avoid
> > logging secrets in `http.c`. Much like the code in `http.c` is guarded
> > via `GIT_TRACE_REDACT` (defaulting to `true`), we guard the new code via
> > `GIT_TRACE2_REDACT` (also defaulting to `true`).
>
> Training users is hard. I appreciate the changes here to make trace2
> not be a leak vector, but is it time to perhaps consider bigger safety
> measures: At the clone/fetch level, automatically warn loudly whenever
> such a URL is provided, accompanied with a note that in the future it
> will be turned into a hard error?
Yes, the password in such a case ends up in the plaintext .git/config
file, which is not great.
There's some discussion and patches here:
https://lore.kernel.org/git/nycvar.QRO.7.76.6.1905172121130.46@tvgsbejvaqbjf.bet/
I meant to follow up on them, but never did.
-Peff
^ permalink raw reply
* Re: [BUG?] Semantics of HEAD when bare cloning non-bare repositories
From: Jeff King @ 2023-11-27 21:56 UTC (permalink / raw)
To: guillaume.yziquel; +Cc: git
In-Reply-To: <179a3f7b2605b295.375e54053ab898bd.31bd44aeb0344c08@hilbert>
On Thu, Nov 23, 2023 at 12:13:27PM +0000, guillaume.yziquel@mailfence.com wrote:
> Observation: When git clone --bare is used on a non-bare repo, the
> HEAD is put in ./refs/HEAD, and conflicts with ./HEAD in the sense
> that they may end up decorelated over time.
That sounds like a bug, but I can't reproduce it here:
$ git init not-bare
$ git -C not-bare commit --allow-empty -m foo
$ git clone --bare not-bare bare.git
$ find bare.git/refs
bare.git/refs
bare.git/refs/tags
bare.git/refs/heads
$ cat bare.git/packed-refs
# pack-refs with: peeled fully-peeled sorted
db58e786007ca405e34df314479e27ddd337957a refs/heads/main
Are you sure that your non-bare repository does not accidentally have a
"refs/HEAD" that should not be there?
> Suggestion: When bare cloning on a non-bare repo, do not put the HEAD
> of the non-bare repo in refs/HEAD like every branch, but treat it
> separately: put it in ./HEAD, not ./refs/HEAD.
That should be what happens already.
-Peff
^ permalink raw reply
* Re: [PATCH] doc: make the gitfile syntax easier to discover
From: Marcel Krause @ 2023-11-28 1:51 UTC (permalink / raw)
To: git mailing list; +Cc: Junio C Hamano, Marcel Krause
In-Reply-To: <xmqqr0kd5i66.fsf@gitster.g>
Thanks for your advice! I'll prepare a new patch.
> The title itself is sufficient, i.e. it had poor visibility, and you
> fix it by giving it better visibility.
Yeah I see now, I should have sent the explanation as cover letter,
not as commit message.
> more relevant is why you needed to find out what the former should
> be in the first place.
My gitfile links worktrees on limited-capability filesystems to a
git repo on a nicer filesystem.
^-- Should I write this in the commit message?
(For the more curious: That way I sync GRUB configs accross lots of
FAT FS thumb drives while having the main repo and main worktree on
an ext3 FS with symlinks and proper owner/group/mode for non-config
files of the project.)
> Do not unnecessary rewrap existing text, only to insert a few
> words, to force reviewers read a lot more than needed.
The shortest diff I can come up with would be:
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -25,3 +25,4 @@ A Git repository comes in two different flavours:
your working tree, containing `gitdir: <path>` to point at the real
-directory that has the repository. This mechanism is often used for
+directory that has the repository.
+This mechanism is called a 'gitfile' and is often used for
a working tree of a submodule checkout, to allow you in the
It loses the double space and thus the sentence boundary information,
but a similar case exists in line 156 (old) so I guess it'll be ok.
> Running "git grep linkgit:gitrepository-layout" would help you find
> the right way to spell this one, I think.
Found and fixed the missing "[5]".
Maybe I'll try and teach our tests to catch that.
^ permalink raw reply
* Re: Migration of git-scm.com to a static web site: ready for review/testing
From: Todd Zullinger @ 2023-11-28 1:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Matt Burke, Victoria Dye, Matthias Aßhauer
In-Reply-To: <1d83b8f8-b739-6277-ac4f-e7fe6ff2d2fe@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]
Hi Johannes,
Johannes Schindelin wrote:
> I found https://lychee.cli.rs/#/ in the meantime and figured out how to
> use it in a local setup:
Nice. That's much faster.
> My most recent lychee run results in 0 broken links.
>
> As a bonus, some of the links that are currently broken on
> https://git-scm.com/ are fixed in https://git.github.io/git-scm.com/.
> For example, following the `Pull Request Referləri` link at the top of
> https://git-scm.com/book/az/v2/Appendix-C:-Git-%C6%8Fmrl%C9%99ri-Plumbing-%C6%8Fmrl%C9%99ri/
> leads to a 404. But following it in
> https://git.github.io/git-scm.com/book/az/v2/Appendix-C:-Git-%C6%8Fmrl%C9%99ri-Plumbing-%C6%8Fmrl%C9%99ri/
> directs the browser to the correct URL:
> https://git.github.io/git-scm.com/book/az/v2/GitHub-Bir-Layih%C9%99nin-Saxlan%C4%B1lmas%C4%B1/#_pr_refs
>
> Another thing that is broken on https://git-scm.com/ are the footnotes in
> the Czech translation of the ProGit book. These were broken in the Hugo
> version, too, but now they are fixed. See e.g.
> https://dscho.github.io/git-scm.com/book/cs/v2/Z%C3%A1klady-pr%C3%A1ce-se-syst%C3%A9mem-Git-Zobrazen%C3%AD-historie-reviz%C3%AD/#_footnotedef_7
> and note that the Rails App redirects to
> https://git-scm.com/book/cs/v2/Z%C3%A1klady-pr%C3%A1ce-se-syst%C3%A9mem-Git-Zobrazen%C3%AD-historie-reviz%C3%AD/ch00/_footnotedef_7
> when clicking on the `[7]`, which 404s.
>
> Could you double-check that the links in the current version?
Since I had it already, I ran linkchecker again. It found
25 errors. I'll attach the output, though I'm not sure if
the list will pass it along or not.
It looks like a number of errors are due to '?' characters
in the generated links, e.g.:
https://git.github.io/git-scm.com/book/en/v2/Getting-Started-What-is-Git?/
Cheers,
--
Todd
[-- Attachment #2: git.github.io_git-scm.com.txt --]
[-- Type: text/plain, Size: 13508 bytes --]
LinkChecker 10.2.1
Copyright (C) 2000-2016 Bastian Kleineidam, 2010-2022 LinkChecker Authors
LinkChecker comes with ABSOLUTELY NO WARRANTY!
This is free software, and you are welcome to redistribute it under
certain conditions. Look at the file `LICENSE' within this distribution.
Read the documentation at https://linkchecker.github.io/linkchecker/
Write comments and bugs to https://github.com/linkchecker/linkchecker/issues
Start checking at 2023-11-25 18:49:01+000
URL `/git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F'
Name `What is Git?'
Parent URL https://git.github.io/git-scm.com/book/en/v2, line 9, col 1
Real URL https://git.github.io/git-scm.com/book/en/v2/Getting-Started-What-is-Git?/
Check time 2.388 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/en/v2/Getting-Started-What-is-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/az/v2/Ba%c5%9flan%c4%9f%c4%b1c-Git-N%c9%99dir%3F'
Name `Git Nədir?'
Parent URL https://git.github.io/git-scm.com/book/az/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/az/v2/Ba%C5%9Flan%C4%9F%C4%B1c-Git-N%C9%99dir?/
Check time 0.074 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/az/v2/Ba%C5%9Flan%C4%9F%C4%B1c-Git-N%C9%99dir?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung%3F'
Name `Erste Schritte'
Parent URL https://git.github.io/git-scm.com/book/de/v2, line 5, col 3159
Real URL https://git.github.io/git-scm.com/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung?/
Check time 0.121 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/de/v2/Erste-Schritte-Was-ist-Git%3F'
Name `Was ist Git?'
Parent URL https://git.github.io/git-scm.com/book/de/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/de/v2/Erste-Schritte-Was-ist-Git?/
Check time 0.068 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/de/v2/Erste-Schritte-Was-ist-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-%c2%bfC%c3%b3mo-obtener-ayuda%3F'
Name `¿Cómo obtener ayuda?'
Parent URL https://git.github.io/git-scm.com/book/es/v2, line 12, col 1
Real URL https://git.github.io/git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-%C2%BFC%C3%B3mo-obtener-ayuda?/
Check time 0.093 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-%C2%BFC%C3%B3mo-obtener-ayuda?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/es/v2/Ramificaciones-en-Git-%c2%bfQu%c3%a9-es-una-rama%3F'
Name `Ramificaciones en Git'
Parent URL https://git.github.io/git-scm.com/book/es/v2, line 21, col 111
Real URL https://git.github.io/git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama?/
Check time 0.094 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/ko/v2/%ec%8b%9c%ec%9e%91%ed%95%98%ea%b8%b0-%eb%b2%84%ec%a0%84-%ea%b4%80%eb%a6%ac%eb%9e%80%3F'
Name `시작하기'
Parent URL https://git.github.io/git-scm.com/book/ko/v2, line 5, col 3159
Real URL https://git.github.io/git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC%EB%9E%80?/
Check time 0.094 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC%EB%9E%80?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/nl/v2/Aan-de-slag-Wat-is-Git%3F'
Name `Wat is Git?'
Parent URL https://git.github.io/git-scm.com/book/nl/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/nl/v2/Aan-de-slag-Wat-is-Git?/
Check time 0.070 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/nl/v2/Aan-de-slag-Wat-is-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/ru/v2/%d0%92%d0%b2%d0%b5%d0%b4%d0%b5%d0%bd%d0%b8%d0%b5-%d0%a7%d1%82%d0%be-%d1%82%d0%b0%d0%ba%d0%be%d0%b5-Git%3F'
Name `Что такое Git?'
Parent URL https://git.github.io/git-scm.com/book/ru/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/ru/v2/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Git?/
Check time 0.075 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/ru/v2/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/sl/v2/Za%c4%8detek-Kaj-je-Git%3F'
Name `Kaj je Git?'
Parent URL https://git.github.io/git-scm.com/book/sl/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/sl/v2/Za%C4%8Detek-Kaj-je-Git?/
Check time 0.071 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/sl/v2/Za%C4%8Detek-Kaj-je-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/ru/v2/%d0%92%d0%b2%d0%b5%d0%b4%d0%b5%d0%bd%d0%b8%d0%b5-%d0%9a%d0%b0%d0%ba-%d0%bf%d0%be%d0%bb%d1%83%d1%87%d0%b8%d1%82%d1%8c-%d0%bf%d0%be%d0%bc%d0%be%d1%89%d1%8c%3F'
Name `Как получить помощь?'
Parent URL https://git.github.io/git-scm.com/book/ru/v2, line 12, col 1
Real URL https://git.github.io/git-scm.com/book/ru/v2/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D0%BB%D1%83%D1%87%D0%B8%D1%82%D1%8C-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C?/
Check time 0.077 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/ru/v2/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D0%BB%D1%83%D1%87%D0%B8%D1%82%D1%8C-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/sr/v2/%d0%9f%d0%be%d1%87%d0%b5%d1%82%d0%b0%d0%ba-%d0%a8%d1%82%d0%b0-%d1%98%d0%b5-%d0%93%d0%b8%d1%82%3F'
Name `Шта је Гит?'
Parent URL https://git.github.io/git-scm.com/book/sr/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/sr/v2/%D0%9F%D0%BE%D1%87%D0%B5%D1%82%D0%B0%D0%BA-%D0%A8%D1%82%D0%B0-%D1%98%D0%B5-%D0%93%D0%B8%D1%82?/
Check time 0.084 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/sr/v2/%D0%9F%D0%BE%D1%87%D0%B5%D1%82%D0%B0%D0%BA-%D0%A8%D1%82%D0%B0-%D1%98%D0%B5-%D0%93%D0%B8%D1%82?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/uz/v2/%d0%98%d1%88-%d0%b1%d0%be%d1%88%d0%bb%d0%b0%d0%bd%d0%b8%d1%88%d0%b8-%d2%9a%d0%b0%d0%bd%d0%b4%d0%b0%d0%b9-%d1%91%d1%80%d0%b4%d0%b0%d0%bc-%d0%be%d0%bb%d0%b8%d1%88-%d0%bc%d1%83%d0%bc%d0%ba%d0%b8%d0%bd%3F'
Name `Қандай ёрдам олиш мумкин?'
Parent URL https://git.github.io/git-scm.com/book/uz/v2, line 12, col 1
Real URL https://git.github.io/git-scm.com/book/uz/v2/%D0%98%D1%88-%D0%B1%D0%BE%D1%88%D0%BB%D0%B0%D0%BD%D0%B8%D1%88%D0%B8-%D2%9A%D0%B0%D0%BD%D0%B4%D0%B0%D0%B9-%D1%91%D1%80%D0%B4%D0%B0%D0%BC-%D0%BE%D0%BB%D0%B8%D1%88-%D0%BC%D1%83%D0%BC%D0%BA%D0%B8%D0%BD?/
Check time 0.074 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/uz/v2/%D0%98%D1%88-%D0%B1%D0%BE%D1%88%D0%BB%D0%B0%D0%BD%D0%B8%D1%88%D0%B8-%D2%9A%D0%B0%D0%BD%D0%B4%D0%B0%D0%B9-%D1%91%D1%80%D0%B4%D0%B0%D0%BC-%D0%BE%D0%BB%D0%B8%D1%88-%D0%BC%D1%83%D0%BC%D0%BA%D0%B8%D0%BD?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/be/v2/%d0%9f%d0%b5%d1%80%d1%88%d1%8b%d1%8f-%d0%ba%d1%80%d0%be%d0%ba%d1%96-What-is-Git%3F'
Name `What is Git?'
Parent URL https://git.github.io/git-scm.com/book/be/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/be/v2/%D0%9F%D0%B5%D1%80%D1%88%D1%8B%D1%8F-%D0%BA%D1%80%D0%BE%D0%BA%D1%96-What-is-Git?/
Check time 0.105 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/be/v2/%D0%9F%D0%B5%D1%80%D1%88%D1%8B%D1%8F-%D0%BA%D1%80%D0%BE%D0%BA%D1%96-What-is-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/it/v2/Per-Iniziare-Cos%e2%80%99%c3%a9-Git%3F'
Name `Cos’é Git?'
Parent URL https://git.github.io/git-scm.com/book/it/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/it/v2/Per-Iniziare-Cos%E2%80%99%C3%A9-Git?/
Check time 0.068 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/it/v2/Per-Iniziare-Cos%E2%80%99%C3%A9-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/ms/v2/Getting-Started-What-is-Git%3F'
Name `What is Git?'
Parent URL https://git.github.io/git-scm.com/book/ms/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/ms/v2/Getting-Started-What-is-Git?/
Check time 0.078 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/ms/v2/Getting-Started-What-is-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/sv/v2/Kom-ig%c3%a5ng-Vad-%c3%a4r-Git%3F'
Name `Vad är Git?'
Parent URL https://git.github.io/git-scm.com/book/sv/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/sv/v2/Kom-ig%C3%A5ng-Vad-%C3%A4r-Git?/
Check time 0.086 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/sv/v2/Kom-ig%C3%A5ng-Vad-%C3%A4r-Git?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/tr/v2/Ba%c5%9flang%c4%b1%c3%a7-Git-Nedir%3F'
Name `Git Nedir?'
Parent URL https://git.github.io/git-scm.com/book/tr/v2, line 8, col 1
Real URL https://git.github.io/git-scm.com/book/tr/v2/Ba%C5%9Flang%C4%B1%C3%A7-Git-Nedir?/
Check time 0.076 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/book/tr/v2/Ba%C5%9Flang%C4%B1%C3%A7-Git-Nedir?/'.
Result Error: 404 Not Found
URL `/git-scm.com/book/fr/v2/Les-branches-avec-Git-Branches-et-fusions'
Name `next'
Parent URL https://git.github.io/git-scm.com/book/fr/v2/Les-branches-avec-Git-Les-branches-en-bref, line 160, col 1436
Real URL https://git.github.io/git-scm.com/book/fr/v2/Les-branches-avec-Git-Branches-et-fusions
Check time 1.887 seconds
Size 1KB
Result Error: 404 Not Found
URL `/git-scm.com/docs/git-submodules'
Parent URL https://git.github.io/git-scm.com/docs/git-submodules/fr, line 2, col 1
Real URL https://git.github.io/git-scm.com/docs/git-submodules/
Check time 5.581 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/docs/git-submodules/'.
Result Error: 404 Not Found
URL `/git-scm.com/docs/git-maintainance'
Parent URL https://git.github.io/git-scm.com/docs/git-maintainance/is, line 2, col 1
Real URL https://git.github.io/git-scm.com/docs/git-maintainance/
Check time 5.867 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/docs/git-maintainance/'.
Result Error: 404 Not Found
URL `/git-scm.com/docs/gitignorar'
Parent URL https://git.github.io/git-scm.com/docs/gitignorar/pt_BR, line 2, col 1
Real URL https://git.github.io/git-scm.com/docs/gitignorar/
Check time 5.546 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/docs/gitignorar/'.
Result Error: 404 Not Found
URL `/git-scm.com/docs/git-fsmonitor----daemon'
Parent URL https://git.github.io/git-scm.com/docs/git-fsmonitor----daemon/pt_BR, line 2, col 1
Real URL https://git.github.io/git-scm.com/docs/git-fsmonitor----daemon/
Check time 5.616 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/docs/git-fsmonitor----daemon/'.
Result Error: 404 Not Found
URL `/git-scm.com/docs/git-pack'
Parent URL https://git.github.io/git-scm.com/docs/git-pack/pt_BR, line 2, col 1
Real URL https://git.github.io/git-scm.com/docs/git-pack/
Check time 4.311 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/docs/git-pack/'.
Result Error: 404 Not Found
URL `/git-scm.com/docs/git-hash'
Parent URL https://git.github.io/git-scm.com/docs/git-hash/fr, line 2, col 1
Real URL https://git.github.io/git-scm.com/docs/git-hash/
Check time 1.156 seconds
Size 1KB
Info Redirected to
`https://git.github.io/git-scm.com/docs/git-hash/'.
Result Error: 404 Not Found
Statistics:
Downloaded: 302.2MB.
Content types: 5656 image, 11838 text, 0 video, 0 audio, 15 application, 29 mail and 620 other.
URL lengths: min=15, max=841, avg=72.
That's it. 18158 links in 19951 URLs checked. 0 warnings found. 25 errors found.
Stopped checking at 2023-11-25 19:34:52+000 (45 minutes, 51 seconds)
^ permalink raw reply
* Re: Fix git-send-email.perl w.r.t. recent Getopt::Long update
From: Todd Zullinger @ 2023-11-28 2:07 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Junio C Hamano, git
In-Reply-To: <20231127093810.2092fe1d@pc09>
Hi,
H.Merijn Brand wrote:
> On Mon, 27 Nov 2023 09:58:52 +0900, Junio C Hamano <gitster@pobox.com> wrote:
>> One downside of unconditional upgrade of the call is, of course,
>> that it would no longer work for those with older Getopt::Long that
>> did not support the "!" suffix. Fortunately, Getopt::Long 2.33
>> started shipping with Perl 5.8.1 that is more than 20 years old, so
>> with the series we accepted, we also have a change to bump the
>> required version of Perl from 5.8.0 to 5.8.1 to make it clear that
>> it is deliberate that we drop the support for anything older at the
>> same time.
>
> The is a no-issue ...
>
> Just the 'use Getopt::Long' is enough to guarantee a working version:
>
> The '!' was already implemented in version 2.10 (April 1997):
> --8<---
> =item !
>
> Option does not take an argument and may be negated, i.e. prefixed by
> "no". E.g. "foo!" will allow B<--foo> (with value 1) and B<-nofoo>
> (with value 0).
> The option variable will be set to 1, or 0 if negated.
> -->8---
The real issue is the lack of support for the '--no-' prefix
when used with the '!' parameter. The '--no-' form is what
has always been documented by git-send-email(1). It was not
supported until Getopt::Long 2.33, included in perl 5.8.1.
Prior, 'foo!' provided --foo and --nofoo but not --no-foo.
But as Junio said, we can accept requiring a perl which was
released sometime in the past 2 decades in order to run the
most recent git release. ;)
Thanks for noticing this and sending a patch!
--
Todd
^ permalink raw reply
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