The test for verifying a signed tag with a missing key has been
updated to point GNUPGHOME to an unused directory rather than
deleting the active gpghome directory, working around a flaky rm
failure caused by the background gpg-agent observed on Alpine.
* hn/t7004-flaky-gpg-test-fix:
t7004: check a missing key without deleting gpghome
"git status" now suggests to use 'git merge --continue', not 'git commit',
when done with conflicts during a 'git merge'.
* je/status-merge-specific-help:
status: suggest `git merge --continue`, not `git commit`
The odb_source API has been refactored to make alternates an
implementation detail of the files backend instead of managing them
at the core object database layer.
* ps/odb-files-alternates:
odb/source: drop `read_alternates` callback
odb/source-files: move alternates into the backend
odb/source-files: extract reading alternates
odb/source: make `will_destroy` an implementation detail
tmp-objdir: replace primary source at creation time
tmp-objdir: manage quarantine as an object directory
tmp-objdir: absorb logic to set and restore primary sources
odb/source-files: add the ability to have multiple object dirs
odb: refactor `odb_find_source()` to yield dirs
odb: refactor `odb_for_each_alternate()` to yield dirs
odb/source-files: introduce `struct odb_files_dir`
commit-graph: stop depending on `struct odb_source`
commit-graph: require resolved packfile paths for `stdin_packs`
The fetch.writeCommitGraph behavior has been optimized to
incrementally update the commit graph using only the newly fetched
commits as seeds. This avoids a full reachability scan of all
references and drastically reduces the post-fetch commit-graph
update time for repositories with many references.
* kk/fetch-write-commit-graph-incremental:
fetch: write commit-graph using updated refs only
test-tool read-graph: add commit-info subcommand
The routine that rewrites the packed-refs file has been optimized to
directly pass unmodified reference records verbatim to the output
via fwrite(3p), instead of redundantly re-formatting them with
fprintf(3p).
* kn/packed-refs-verbatim-write:
packed-refs: use `fwrite()` when passing refs verbatim
Validation of the 'fetch.followRemoteHEAD' configuration variable
has been deferred to when it is actually used, preventing irrelevant
warnings during 'git fetch' invocations that do not consult it.
* ch/fetch-followremotehead-lazy-validation:
fetch.c: defer fetch.followRemoteHEAD validation
Closing a packfile did not evict the entries belonging to it from
the delta base cache, which could lead to data corruption when a
newly allocated packfile happened to reuse the same memory address.
The cache eviction logic has been updated to remove these stale
entries upon closing a pack
* ps/packfile-stale-delta-base-cache-fix:
packfile: fix corruption due to stale delta base cache entries
packfile: move around `close_pack()`
Replace a link to a site that disappeared with a link to web archive
of the last known good copy.
* dk/fix-shattered-io-link:
doc: fix shattered.io link
A test script (t0450) has been updated to use the test_path_is_file
and test_path_is_missing helper functions, which provides better
diagnostic output on failure.
* ma/t0450-use-test-path-is-file:
t0450: use test_path_is_file and test_path_is_missing
The requirement for a 'SYNOPSIS' section in section 7 manual pages
has been relaxed by updating the linter script, and dummy
'SYNOPSIS' sections from existing section 7 documentation have been
removed to improve the rendered output
* je/doc-section-7-synopsis:
doc: don't require a SYNOPSIS in section 7
The shell quoting of a lazy prereq script was quoted incorrectly and
allowed variables dereferenced at the wrong moment, breaking the
curl version detection.
* jk/t5551-test-shell-quote-fix:
t5551: fix quoting in curl version bug prereq
During a merge conflict, we suggest using --continue to continue the
merge for rebase, revert, and cherry-pick.
Change the `git merge` advice to be consistent. 367ff69428
(merge: add '--continue' option as a synonym for 'git commit', 2016-12-14)
says that `git merge --continue` is intended to be a synonym for
`git commit`, and the `git merge` man page already suggests to use
`git merge --continue`.
Signed-off-by: Julia Evans <julia@jvns.ca>
Acked-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "verify signed tag fails when public key is not present" test
deletes gpghome to lose the key, and this sometimes fails on Alpine
with
rm: can't remove 'gpghome/S.gpg-agent.extra': No such file or directory
Point GNUPGHOME at an unused directory for the verification, which is
how t7510 checks a signature whose key is unknown.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation for core.pager has been updated to provide
examples of overriding the LESS environment variable for custom
pagers by prefixing the pager command in the configuration.
* tz/doc-override-less-env:
doc: add more examples of overriding LESS in core.pager
The commit map populated from the state branch in 'git
filter-branch' has been corrected to parse the map using the
original-to-rewritten order.
* gm/filter-branch-state-map-fix:
filter-branch: fix commit map init from state branch
Fix definition for the "--all" option to use symbolic constant
in the options[] array passed to parse_options API.
* pw/stash-all-parseopt-fix:
stash: use named constant when parsing "--all"
Now that alternates are an implementation detail of the "files" backend
there is no reason anymore to expose them anywhere else. The callback to
read alternates is thus no longer required. Remove it.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally, when designing pluggable object databases the goal was that
the object database can have multiple sources, and every source attached
to it could use a different backend. This would have allowed for quite a
lot of flexibility, as you could trivially mix and match different kinds
of object storages in whatever way you like.
But while well-intentioned, this design led to a bunch of conceptual
problems:
- We're now trying to read objects in source order, whereas we
previously tried to read objects via packfiles before trying to read
them via loose objects. This led to a performance regression when
using alternates or when using a quarantine directory.
- Some data structures are supposed to only ever exist once, like for
example bitmaps and commit graphs. At the same time, those data
structures also span across the union of all objects, so they may
cross sources.
- It is unclear how we can extend GIT_OBJECT_DIRECTORY or
GIT_ALTERNATE_OBJECT_DIRECTORIES to become backend-agnostic in a
backwards-compatible way. In general, introducing an object storage
extension into the current status quo where alternates may have to
be extended to become generic was proving to be painful.
- Some mechanisms of alternates assume way too much about how exactly
their backends work. Alternate refs for example assume that the
alternate is backed by a filesystem path, and that this filesystem
path may also allow us to read references. This is not a given
though, as backends may not even have local data at all.
In short, there are a bunch of conceptual mismatches when we have
alternates and pluggable object databases coexist. So while the original
idea was nice, it does not result in a system that is easy to reason
about.
Correct course by moving alternates into the "files" source itself so
that it becomes an implementation detail thereof so that we can avoid
all of these shortcomings. While it's unfortunate that we cannot easily
mix and match sources now, that ability doesn't go away. It's still very
much feasible to introduce a new backend that allows for exactly that
use case, and such a backend may also be a lot more flexible as we can
now add new logic to determine which objects should be stored where. So
the original motivation for having per-source backends can still be
realized with the new architecture.
Note that as part of this move, we also handle the GIT_OBJECT_DIRECTORY
and GIT_ALTERNATE_OBJECT_DIRECTORIES environment variables in the
"files" backend. This may be surprising at first, but object directories
are very much a concept of that backend, too. So these variables would
have bad interactions with other backends, and they create a bit of a
mismatch with the eventual object storage extension that we plan to
introduce.
Note that this commit is way larger than I'd like it to be. I'm sorry, I
couldn't find a way to split it up further. That being said, most of the
changes are straight-forward conversions that go from iterating over
sources to iterating over object directories. The more involved changes
are moving the infrastructure to track individual sources from "odb.c"
and moving them into "odb/source-files.c".
This also serves to show a bit of a who's-who of commands that don't
work properly with pluggable object databases. Almost all of these
commands are related to housekeeping though -- some of them will be
converted eventually, like for example commit graphs or MIDXs. But many
of them will stay incompatible going forward as they are simply too
specific to the "files" backend.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the next commit we'll add a new callsite that wants to read
alternates without having a proper object database source for a given
alternate available to it. Prepare for this by extracting the logic into
a separate function that only requires an object directory path as
input.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `struct odb_source::will_destroy` flag tracks whether a source is
part of a transaction that we know we'll destruct anyway. If so, the
backend can optimize for that particular case, for example by not
flushing any data to disk.
While the intent is sensible, it assumes that transactions are backed by
a separate source that's being linked into the object database. But that
may or may not be true, as backends may have significantly better ways
to achieve the same. So the assumption doesn't make much sense in the
first place, as we're now tracking backend-specific details on the
generic `struct odb_source` level.
Move the field from the generic source into the "loose" source, as this
is the only source that ever makes use of it anyway.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When creating transactions via the "tmp-objdir" subsystem callers are
expected to first call `tmp_objdir_create()` to create the quarantine
directory and then `tmp_objdir_replace_primary_odb()` to activate that
quarantine directory as the primary object database source so that all
newly written objects are written into it.
This dance is performed by all users of temporary object directories, so
that makes the setup unnecessarily involved. Merge the logic to replace
the primary object database source into `tmp_objdir_create()` to
simplify the dance.
Note that with the quarantine directory being installed by
`tmp_objdir_create()`, users of this function no longer get a pointer to
the underlying quarantine directory. So instead of repreparing only that
directory, we now reprepare the whole source instead, and as we know
that the source has wired up the quarantine directory already, this will
cause us to reprepare the quarantine directory, too.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When creating a quarantine directory via the "tmp-objdir" subsystem we
create a new "files" backend that new objects part of the transaction
can be written to. In a future commit though we'll move handling of
alternates into the "files" backend, and as part of that it will no
longer be possible for us to have multiple sources attached to a single
object database.
In a preceding commit, we have prepared the "files" backend to be able
to handle multiple object directories. We don't use that mechanism for
alternates yet, but will start doing so in a subsequent commit. But with
that infrastructure ready we can already migrate tmp-objdirs over to use
this new mechanism.
Adapt the subsystem so we create a `struct odb_files_dir` instead of a
new "files" source.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The functions `odb_set_temporary_primary_source()` and
`odb_restore_primary_source()` can be used to adapt the primary object
database source. Nowadays though we only have a single user of this
subsystem left, which is the "tmp-objdir" subsystem.
Despite that, this functionality is also becoming less useful overall as
alternates are becoming an implementation detail of the "files" backend.
And with that change, there will only ever be a single source attached
to the object database anyway.
Move the logic into the "tmp-objdir" subsystem accordingly.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a subsequent commit we'll migrate handling of alternates into the
"files" backend. As part of that, the backend will need to grow the
ability to handle multiple object directories for alternates and for
transactions.
Introduce a `struct odb_files_dir::next` pointer so that we can have
multiple directories. Adapt the backend to loop through this list as
necessary. In general:
- For reading paths we will loop through all object directories until
we have found the object.
- For writing paths we will typically write to the first of our object
directories.
This mechanism isn't used yet as we still only ever have a single object
directory at the current point in time. But that will change over
subsequent commits.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Similar as in the preceding commit, `odb_find_source()` can be used to
yield a single source by its object directory. This function is also
specific to the "files" backend once alternates are an implementation
detail thereof.
Refactor it to be specific to the "files" backend and return an `struct
odb_files_dir` to prepare for moving alternates into the "files" source.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function `odb_for_each_alternate()` iterates through all alternates
of an object database. This is becoming an implementation detail of the
"files" backend though, where each alternate will be represented by one
`struct odb_files_dir`.
Adapt `odb_for_each_alternate()` to already iterate through these
structs instead of iterating through sources.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "files" object database source consists of two separate backends for
storing loose and packed objects. These are managed as somewhat separate
entities even though they derive from the same object directory, whether
it's the primary object directory or that one from an alternate.
In a subsequent commit we'll move the handling of alternates into the
"files" backend completely so that it becomes another implementation
detail thereof. As part of this, we'll want to keep track of both of
these sub-sources as a single entity derived from their respective
object directory.
Prepare for this change by introducing a new `struct odb_files_dir` that
encapsulates them. For now, every "files" source has exactly one such
directory. In a subsequent commit though, we'll make it a linked list of
directories so that we can manage multiple such directories in a single
"files" source.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To read or write a commit graph we require access to the repository that
the graph should be read from or written for as well as the object
directory to derive its location. Instead of passing in these two bits
of information explicitly though, we pass in a `struct odb_source`,
which carries with it both of these pieces of information.
But ultimately, this is somewhat flawed as we now assume that the source
even has an on-disk representation, and furthermore we assume that the
commit graphs would live in ".git/objects/info". This is true for the
"files" backend, but it's not necessarily true for any other backend
that we may eventually want to introduce. So eventually, we'll want to
evolve the commit-graph subsystem to become agnostic of the backend's
layout and let the backend itself decide where to read a commit graph
from or where to write it to.
We're not there yet to do that switch, but the current design is already
causing issues for the intent of this patch series where we want to move
alternates into the "files" backend.
Convert the subsystem to take a repository plus an object directory path
instead. This unblocks moving around alternates, and it's also a step
in the right direction for moving commit graphs into the source in a
later series.
Note that we previously compared the `struct odb_source` pointers of two
commit graphs to figure out whether they were located in the same object
directory, whereas we now have to compare their paths. Callers may pass
in those paths in different forms though, for example relative to the
current working directory or as absolute paths. Convert the object
directory into an absolute path both when loading and when writing
commit graphs so that the comparisons become more robust.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users can ask git-commit-graph(1) to write a commit graph specifically
for a set of packfiles via the "--stdin-packs" option. Those users are
expected to pass in relative paths, and those eventually get resolved in
`fill_oids_from_packs()`. This ties the logic in "commit-graph.c" to the
specific object database source, as the subsystem now needs to assume
where a specific packfile is located relative to the source itself.
Refactor the logic to instead require the caller to pass in resolved
packfiles to untangle that dependency. This also makes the next change
easier to implement, where we'll get rid of passing the source to the
commit-graph subsystem.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When fetch.writeCommitGraph was introduced in 50f26bd035 (fetch: add
fetch.writeCommitGraph config setting, 2019-09-02), the stated goal
was to stay updated with the latest commits after fetching new
objects. The implementation used write_commit_graph_reachable()
because it was the only API available, but two things have changed
since then:
1. write_commit_graph() was added, and it accepts an explicit set of
commits as seeds, enabling more targeted commit-graph updates.
2. The ref-scanning callback add_ref_to_set() became more expensive
in 630cd5194e (commit-graph.c: peel refs in 'add_ref_to_set',
2020-07-22) when it started to validate the refs against the odb
for correctness. On a repository with many refs, this makes the
full reachable scan unnecessarily costly for a targeted fetch.
Optimize the commit-graph write by using only the newly updated refs
as seeds instead of scanning all refs after every fetch. To keep
this change small, skip the optimization for multi-remote fetches
(since that would require propagating the set of refs across process
boundaries).
This relies on the commit-graph write being additive, keeping the
commits that are already in the graph. fetch already operates in
this mode (COMMIT_GRAPH_WRITE_SPLIT) and now that becomes
required for correctness. Without that mode, the write would
replace the commit-graph and lose other commits.
After fetch_one() returns, call prepare_commit_graph() (which is
made non-static by this commit) to determine the graph-write mode:
- If no commit-graph exists yet, fall back to the full reachable
scan so the first graph creation covers all refs.
- If a commit-graph exists and the fetch updated at least one ref,
write incrementally using only the new refs as seeds.
- If a commit-graph exists but the fetch is a no-op, skip the
commit-graph write entirely.
- For the multi-remote path (fetch --all), where child processes
do the actual fetching, fall back to the full reachable scan.
Full commit-graph coverage of all refs remains the responsibility
of "git maintenance", "git gc" and "git commit-graph write".
Regular Git operations may trigger "git maintenance run --auto",
which periodically rebuilds the commit-graph from all reachable
refs.
The effect was measured on a synthetic setup: git.git with 200K
extra packed refs (~206K total), a local file:// remote, an existing
split commit-graph and a warm page cache. The times below are the
median of 9 runs of the trace2 region fetch/write-commit-graph:
scenario before after
no-op fetch 380 ms (skipped)
1 ref updated 357 ms 9.3 ms
10 refs updated 359 ms 8.9 ms
Signed-off-by: Kristofer Karlsson <krka@spotify.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test infrastructure has no way to check whether a specific commit
is present in the commit-graph, making it hard to verify graph state
after operations like fetch.
Add a "commit-info" subcommand to test-tool read-graph that queries
whether specific commits are present in the commit-graph and prints
their generation numbers. Returns 1 if any commit is not found.
Signed-off-by: Kristofer Karlsson <krka@spotify.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'format-patch' command has been updated with options to
configure notes specifically for range-diff output, allowing them to
differ from the notes displayed on the patches themselves.
* kh/format-patch-range-diff-notes:
format-patch: learn --[no-]range-diff-notes
format-patch: simplify get_notes_arg parameters
The documentation for 'git interpret-trailers' has been updated to
fix the grammatical errors in the descriptions of command examples.
* kh/doc-trailers-cmd-examples:
doc: interpret-trailers: fix cmd examples
The documentation for 'git remote set-head' has been updated to
clarify that it only modifies the local repository's remote-tracking
symbolic reference, and does not alter the target remote
repository's own 'HEAD'.
* mg/doc-remote-set-head:
doc: remote: say that it only affects the local repository
The parse-options API has been updated to support grouping
subcommands, and the 'git refs' command has been updated to use this
new feature to categorize its subcommands in its help output.
* ps/parse-options-subcommand-groups:
builtin/refs: introduce subcommand groups
parse-options: allow grouping subcommands
parse-options: extract functions to print single option
parse-options: fix completion format when first option is skipped
The @{upstream} notation had short-hand @{u} from the beginning,
and @{push} learned corresponding @{p} to match.
* hn/object-name-push-short:
object-name: accept @{p} as short for @{push}
The 'git-contacts' program (in contrib/) has been taught to read
patches from the standard input stream when an explicit dash ('-') is
passed in place of a file.
* bc/git-contacts-stdin:
git-contacts: allow inputting patch via stdin
The 'git var' command has been updated to output individual components
of the author and committer identities, take multiple keys on the
command-line, and support NUL-delimited output with the '-z' option.
* ap/var-broken-down-idents:
var: add broken-out identity variables
var: accept more than one variable
var: add "-z" output mode
var: represent multi-valued variables with a string_list
The handling of index conflicts in 'git stash apply --index' has
been optimized. Instead of relying on expensive external
subprocesses using 'git diff-tree' and 'git apply', the index is now
merged in-core using the merge-ort machinery, which fixes a
concurrent lock file issue with autostash.
* dk/stash-apply-index-incore:
builtin/stash: merge index in-core
t3903: test failed "stash apply --index"
stash: prepare merge options earlier
builtin/stash: remove unused header
The internal diff and merge machinery has been updated to use
standard size_t types rather than signed longs for buffer
allocations and offsets, preventing subtle overflow issues on LLP64
architectures, and plugging uninitialized memory leaks along error
paths.
* jk/xdiff-size_t:
merge-ll: report an error when reading external merge results fails
merge-ll: handle external driver status before reading result
merge-ll: use read_mmfile() to read external merge results
xdiff: NUL-terminate buffers read by read_mmfile()
xdiff: use size_t for buffer sizes
xdiff: replace mmbuffer_t with mmfile_t
xdiff: clean up read_mmfile() allocations on error
The internal representation of timezones in the reflog for the
reftable format has been fixed to match the specification, which
dictates an offset in minutes rather than the parsed "+HHMM" integer
representation.
* ps/reftable-reflog-timezone:
refs/reftable: fix on-disk representation of reflog timezones
t/helper: fix segfault in "dump-reftable -t"
date: add helpers to convert between "+HHMM" timezones and minutes
The `t5520` test script has been updated to disable reflog expiration.
This prevents test flakiness caused by the auto-maintenance
reflog-expire task, which would otherwise immediately expire the
test's reflogs due to them carrying hardcoded timestamps from 2005.
* tb/t5520-reflog-expire:
t5520: don't expire reflogs where it matters
CI resource exhaustion during test runs on GitHub Actions has been
mitigated by switching a comparison of a huge output to use a binary
comparison, and by capping the parallel jobs on Linux to the number
of available CPUs.
* td/ci-large-test-resources:
ci: use twice the CPU count on both providers
t4205: compare huge output without diff
The build configurations for Meson have been optimized to avoid
recompiling HTTP sources multiple times and to utilize precompiled
headers for test-helpers and unit tests, reducing clean build times.
Additionally, the shell completion tests and GitLab CI MSVC runner
jobs have been fixed.
* ps/meson-improvements:
gitlab-ci: fix hanging MSVC jobs
meson: update wrappers
meson: fix outdated completion helpers
meson: use precompiled headers for unit tests
meson: use precompiled headers for our test-helper
meson: don't recompile git-remote-http(1) multiple times for tests
meson: avoid recompiling HTTP sources several times
The `write_with_updates()` function uses a `struct ref_iterator` to
iterate over all refs to write to the temporary packed-refs file. It
receives the iterator from `packed_ref_iterator_begin()` which takes a
snapshot of the 'packed-refs' file.
While writing to the new packed-refs file, writes are routed via
`write_packed_entry()` which uses `fprintf()`. Even for references which
haven't changed, we use the same mechanism. This is slow since we need
to do string parsing and formatting. Instead, let's track the position
of unchanged references in the snapshot iterator and directly write
verbatim via `fwrite()`.
With this, any sanitization which was happening as a side effect of
reformatting is now lost. But that was never the job of this section of
the code, since the main intention is to simply rewrite the remaining
refs post deletion of the selective few.
This removes the unnecessary formatting operation involved. We can see a
consistent ~20% performance improvement when deleting from packed
references.
Benchmark 1: update-ref: delete ref (refcount = 100000, revision = master)
Time (mean ± σ): 28.7 ms ± 1.7 ms [User: 22.5 ms, System: 5.9 ms]
Range (min … max): 26.7 ms … 33.3 ms 46 runs
Benchmark 2: update-ref: delete ref (refcount = 100000, revision = b4/kn-speedup-packed-refs)
Time (mean ± σ): 23.8 ms ± 1.2 ms [User: 17.5 ms, System: 6.0 ms]
Range (min … max): 22.1 ms … 27.7 ms 56 runs
Summary
update-ref: delete ref (refcount = 100000, revision = b4/kn-speedup-packed-refs) ran
1.21 ± 0.09 times faster than update-ref: delete ref (refcount = 100000, revision = master)
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since we published this document the domain has been taken over and no
longer reflects the original content. Link to the last good Web Archive
snapshot so folks can still retrieve the SHAttered information.
Suggested-by: Mae Eckert <mae.eckert@albellus.de>
Signed-off-by: D. Ben Knoble <ben.knoble@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove the SYNOPSIS section from the section 7 man pages where
appropriate, to avoid having a section that contains no information.
It's not the norm in section 7 to always require a SYNOPSIS.
Update the perl script with a special case for section 7.
Tested by running `make lint-docs`, and looked at the renaming synopses
with this fish script snippet:
for i in *.7
echo $i; grep SYNOPSIS -A 5 (string replace .7 .adoc $i)
end
Co-authored-by: Tuomas Ahola <taahol@utu.fi>
Signed-off-by: Tuomas Ahola <taahol@utu.fi>
Signed-off-by: Julia Evans <julia@jvns.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace raw 'test -f' and '! test -f' assertions with the test helper
functions 'test_path_is_file' and 'test_path_is_missing' to provide
diagnostic output when an assertion fails.
Signed-off-by: Muhammed Dilshad A <dilsheddilu123@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have a prereq snippet that invokes awk. The awk script's $1, etc,
variables need to be quoted to avoid shell interpolation. We correctly
use a single-quote inside the prereq snippet, but the snippet itself is
contained in double-quotes. So we interpolate "$1" into whatever value
that happens to have in the outer shell, and eval nonsense like:
awk '(--some-garbage == 7 && --other-garbage >= 88) ...'
As a result, we don't think we have a buggy curl version even when we
do, and run the test anyway. But of course it's easy not to notice,
since this prereq was protecting us from a racy bug. It only breaks
sometimes.
There are a few options for fixing the quoting:
1. Backslash-escaping the dollar signs. This is perhaps the least-ugly
version, but it's a minor hassle to remember if somebody touches
the code later.
2. Single-quote the snippet, then quote interior single-quotes as
'\''. Reasonably obvious, but ugly.
3. Use the '<<\EOT' here-doc trick to specify the snippet. This would
look nice, but we don't yet support it for prereqs. ;)
This patch uses (2), and we can circle back to (3) to make it look nicer
later.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano