]> git.ipfire.org Git - thirdparty/git.git/log
thirdparty/git.git
4 months agoMerge branch 'ps/refstorage-extension'
Junio C Hamano [Tue, 16 Jan 2024 18:11:57 +0000 (10:11 -0800)] 
Merge branch 'ps/refstorage-extension'

Introduce a new extension "refstorage" so that we can mark a
repository that uses a non-default ref backend, like reftable.

* ps/refstorage-extension:
  t9500: write "extensions.refstorage" into config
  builtin/clone: introduce `--ref-format=` value flag
  builtin/init: introduce `--ref-format=` value flag
  builtin/rev-parse: introduce `--show-ref-format` flag
  t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar
  setup: introduce GIT_DEFAULT_REF_FORMAT envvar
  setup: introduce "extensions.refStorage" extension
  setup: set repository's formats on init
  setup: start tracking ref storage format
  refs: refactor logic to look up storage backends
  worktree: skip reading HEAD when repairing worktrees
  t: introduce DEFAULT_REPO_FORMAT prereq

4 months agoMerge branch 'ps/reftable-fixes-and-optims'
Junio C Hamano [Tue, 16 Jan 2024 18:11:56 +0000 (10:11 -0800)] 
Merge branch 'ps/reftable-fixes-and-optims'

More fixes and optimizations to the reftable backend.

* ps/reftable-fixes-and-optims:
  reftable/merged: transfer ownership of records when iterating
  reftable/merged: really reuse buffers to compute record keys
  reftable/record: store "val2" hashes as static arrays
  reftable/record: store "val1" hashes as static arrays
  reftable/record: constify some parts of the interface
  reftable/writer: fix index corruption when writing multiple indices
  reftable/stack: do not auto-compact twice in `reftable_stack_add()`
  reftable/stack: do not overwrite errors when compacting

4 months agoThe seventh batch
Junio C Hamano [Fri, 12 Jan 2024 23:58:36 +0000 (15:58 -0800)] 
The seventh batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>
4 months agoMerge branch 'cp/git-flush-is-an-env-bool'
Junio C Hamano [Sat, 13 Jan 2024 00:09:57 +0000 (16:09 -0800)] 
Merge branch 'cp/git-flush-is-an-env-bool'

Unlike other environment variables that took the usual
true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1,
which has been corrected.

* cp/git-flush-is-an-env-bool:
  write-or-die: make GIT_FLUSH a Boolean environment variable

4 months agoMerge branch 'ms/rebase-insnformat-doc-fix'
Junio C Hamano [Sat, 13 Jan 2024 00:09:56 +0000 (16:09 -0800)] 
Merge branch 'ms/rebase-insnformat-doc-fix'

Docfix.

* ms/rebase-insnformat-doc-fix:
  Documentation: fix statement about rebase.instructionFormat

4 months agoMerge branch 'jx/sideband-chomp-newline-fix'
Junio C Hamano [Sat, 13 Jan 2024 00:09:56 +0000 (16:09 -0800)] 
Merge branch 'jx/sideband-chomp-newline-fix'

Sideband demultiplexer fixes.

* jx/sideband-chomp-newline-fix:
  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

4 months agoMerge branch 'tb/multi-pack-verbatim-reuse'
Junio C Hamano [Sat, 13 Jan 2024 00:09:56 +0000 (16:09 -0800)] 
Merge branch 'tb/multi-pack-verbatim-reuse'

Streaming spans of packfile data used to be done only from a
single, primary, pack in a repository with multiple packfiles.  It
has been extended to allow reuse from other packfiles, too.

* tb/multi-pack-verbatim-reuse: (26 commits)
  t/perf: add performance tests for multi-pack reuse
  pack-bitmap: enable reuse from all bitmapped packs
  pack-objects: allow setting `pack.allowPackReuse` to "single"
  t/test-lib-functions.sh: implement `test_trace2_data` helper
  pack-objects: add tracing for various packfile metrics
  pack-bitmap: prepare to mark objects from multiple packs for reuse
  pack-revindex: implement `midx_pair_to_pack_pos()`
  pack-revindex: factor out `midx_key_to_pack_pos()` helper
  midx: implement `midx_preferred_pack()`
  git-compat-util.h: implement checked size_t to uint32_t conversion
  pack-objects: include number of packs reused in output
  pack-objects: prepare `write_reused_pack_verbatim()` for multi-pack reuse
  pack-objects: prepare `write_reused_pack()` for multi-pack reuse
  pack-objects: pass `bitmapped_pack`'s to pack-reuse functions
  pack-objects: keep track of `pack_start` for each reuse pack
  pack-objects: parameterize pack-reuse routines over a single pack
  pack-bitmap: return multiple packs via `reuse_partial_packfile_from_bitmap()`
  pack-bitmap: simplify `reuse_partial_packfile_from_bitmap()` signature
  ewah: implement `bitmap_is_empty()`
  pack-bitmap: pass `bitmapped_pack` struct to pack-reuse functions
  ...

4 months agoMerge branch 'jk/t1006-cat-file-objectsize-disk'
Junio C Hamano [Sat, 13 Jan 2024 00:09:56 +0000 (16:09 -0800)] 
Merge branch 'jk/t1006-cat-file-objectsize-disk'

Test update.

* jk/t1006-cat-file-objectsize-disk:
  t1006: prefer shell loop to awk for packed object sizes
  t1006: add tests for %(objectsize:disk)

4 months agoMerge branch 'jw/builtin-objectmode-attr'
Junio C Hamano [Sat, 13 Jan 2024 00:09:55 +0000 (16:09 -0800)] 
Merge branch 'jw/builtin-objectmode-attr'

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.

* jw/builtin-objectmode-attr:
  attr: add builtin objectmode values support

4 months agoMerge branch 'js/contributor-docs-updates'
Junio C Hamano [Sat, 13 Jan 2024 00:09:55 +0000 (16:09 -0800)] 
Merge branch 'js/contributor-docs-updates'

Doc update.

* js/contributor-docs-updates:
  SubmittingPatches: hyphenate non-ASCII
  SubmittingPatches: clarify GitHub artifact format
  SubmittingPatches: clarify GitHub visual
  SubmittingPatches: provide tag naming advice
  SubmittingPatches: update extra tags list
  SubmittingPatches: discourage new trailers
  SubmittingPatches: drop ref to "What's in git.git"
  CodingGuidelines: write punctuation marks
  CodingGuidelines: move period inside parentheses

5 months agoThe sixth batch
Junio C Hamano [Mon, 8 Jan 2024 22:05:24 +0000 (14:05 -0800)] 
The sixth batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoMerge branch 'rs/mem-pool-improvements'
Junio C Hamano [Mon, 8 Jan 2024 22:05:16 +0000 (14:05 -0800)] 
Merge branch 'rs/mem-pool-improvements'

MemPool allocator fixes.

* rs/mem-pool-improvements:
  mem-pool: simplify alignment calculation
  mem-pool: fix big allocations

5 months agoMerge branch 'rs/fast-import-simplify-mempool-allocation'
Junio C Hamano [Mon, 8 Jan 2024 22:05:16 +0000 (14:05 -0800)] 
Merge branch 'rs/fast-import-simplify-mempool-allocation'

Code simplification.

* rs/fast-import-simplify-mempool-allocation:
  fast-import: use mem_pool_calloc()

5 months agoMerge branch 'en/sparse-checkout-eoo'
Junio C Hamano [Mon, 8 Jan 2024 22:05:16 +0000 (14:05 -0800)] 
Merge branch 'en/sparse-checkout-eoo'

"git sparse-checkout (add|set) --[no-]cone --end-of-options" did
not handle "--end-of-options" correctly after a recent update.

* en/sparse-checkout-eoo:
  sparse-checkout: be consistent with end of options markers

5 months agoMerge branch 'jc/sparse-checkout-set-default-fix'
Junio C Hamano [Mon, 8 Jan 2024 22:05:16 +0000 (14:05 -0800)] 
Merge branch 'jc/sparse-checkout-set-default-fix'

"git sparse-checkout set" added default patterns even when the
patterns are being fed from the standard input, which has been
corrected.

* jc/sparse-checkout-set-default-fix:
  sparse-checkout: use default patterns for 'set' only !stdin

5 months agoMerge branch 'en/header-cleanup'
Junio C Hamano [Mon, 8 Jan 2024 22:05:15 +0000 (14:05 -0800)] 
Merge branch 'en/header-cleanup'

Remove unused header "#include".

* en/header-cleanup:
  treewide: remove unnecessary includes in source files
  treewide: add direct includes currently only pulled in transitively
  trace2/tr2_tls.h: remove unnecessary include
  submodule-config.h: remove unnecessary include
  pkt-line.h: remove unnecessary include
  line-log.h: remove unnecessary include
  http.h: remove unnecessary include
  fsmonitor--daemon.h: remove unnecessary includes
  blame.h: remove unnecessary includes
  archive.h: remove unnecessary include
  treewide: remove unnecessary includes in source files
  treewide: remove unnecessary includes from header files

5 months agoMerge branch 'ml/doc-merge-updates'
Junio C Hamano [Mon, 8 Jan 2024 22:05:15 +0000 (14:05 -0800)] 
Merge branch 'ml/doc-merge-updates'

Doc update.

* ml/doc-merge-updates:
  Documentation/git-merge.txt: use backticks for command wrapping
  Documentation/git-merge.txt: fix reference to synopsis

5 months agoMerge branch 'jc/archive-list-with-extra-args'
Junio C Hamano [Mon, 8 Jan 2024 22:05:14 +0000 (14:05 -0800)] 
Merge branch 'jc/archive-list-with-extra-args'

"git archive --list extra garbage" silently ignored excess command
line parameters, which has been corrected.

* jc/archive-list-with-extra-args:
  archive: "--list" does not take further options

5 months agowrite-or-die: make GIT_FLUSH a Boolean environment variable
Chandra Pratap [Thu, 4 Jan 2024 10:20:17 +0000 (10:20 +0000)] 
write-or-die: make GIT_FLUSH a Boolean environment variable

Among Git's environment variables, the ones marked as "Boolean"
accept values in a way similar to Boolean configuration variables,
i.e. values like 'yes', 'on', 'true' and positive numbers are
taken as "on" and values like 'no', 'off', 'false' are taken as
"off".

GIT_FLUSH can be used to force Git to use non-buffered I/O when
writing to stdout. It can only accept two values, '1' which causes
Git to flush more often and '0' which makes all output buffered.
Make GIT_FLUSH accept more values besides '0' and '1' by turning it
into a Boolean environment variable, modifying the required logic.
Update the related documentation.

Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoDocumentation: fix statement about rebase.instructionFormat
Maarten van der Schrieck [Wed, 3 Jan 2024 18:14:23 +0000 (18:14 +0000)] 
Documentation: fix statement about rebase.instructionFormat

Since commit 62db5247 (rebase -i: generate the script via
rebase--helper, 2017-07-14), the short hash is given in
rebase-todo. Specifying rebase.instructionFormat does not alter this
behavior, contrary to what the documentation implies.

Signed-off-by: Maarten van der Schrieck <maarten@thingsconnected.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoreftable/merged: transfer ownership of records when iterating
Patrick Steinhardt [Wed, 3 Jan 2024 06:22:43 +0000 (07:22 +0100)] 
reftable/merged: transfer ownership of records when iterating

When iterating over records with the merged iterator we put the records
into a priority queue before yielding them to the caller. This means
that we need to allocate the contents of these records before we can
pass them over to the caller.

The handover to the caller is quite inefficient though because we first
deallocate the record passed in by the caller and then copy over the new
record, which requires us to reallocate memory.

Refactor the code to instead transfer ownership of the new record to the
caller. So instead of reallocating all contents, we now release the old
record and then copy contents of the new record into place.

The following benchmark of `git show-ref --quiet` in a repository with
around 350k refs shows a clear improvement. Before:

    HEAP SUMMARY:
        in use at exit: 21,163 bytes in 193 blocks
      total heap usage: 708,058 allocs, 707,865 frees, 36,783,255 bytes allocated

After:

    HEAP SUMMARY:
        in use at exit: 21,163 bytes in 193 blocks
      total heap usage: 357,007 allocs, 356,814 frees, 24,193,602 bytes allocated

This shows that we now have roundabout a single allocation per record
that we're yielding from the iterator. Ideally, we'd also get rid of
this allocation so that the number of allocations doesn't scale with the
number of refs anymore. This would require some larger surgery though
because the memory is owned by the priority queue before transferring it
over to the caller.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoreftable/merged: really reuse buffers to compute record keys
Patrick Steinhardt [Wed, 3 Jan 2024 06:22:39 +0000 (07:22 +0100)] 
reftable/merged: really reuse buffers to compute record keys

In 829231dc20 (reftable/merged: reuse buffer to compute record keys,
2023-12-11), we have refactored the merged iterator to reuse a pair of
long-living strbufs by relying on the fact that `reftable_record_key()`
tries to reuse already allocated strbufs by calling `strbuf_reset()`,
which should give us significantly fewer reallocations compared to the
old code that used on-stack strbufs that are allocated for each and
every iteration. Unfortunately, we called `strbuf_release()` on these
long-living strbufs that we meant to reuse on each iteration, defeating
the optimization.

Fix this performance issue by not releasing those buffers on iteration
anymore, where we instead rely on `merged_iter_close()` to release the
buffers for us.

Using `git show-ref --quiet` in a repository with ~350k refs this leads
to a significant drop in allocations. Before:

    HEAP SUMMARY:
        in use at exit: 21,163 bytes in 193 blocks
      total heap usage: 1,410,148 allocs, 1,409,955 frees, 61,976,068 bytes allocated

After:

    HEAP SUMMARY:
        in use at exit: 21,163 bytes in 193 blocks
      total heap usage: 708,058 allocs, 707,865 frees, 36,783,255 bytes allocated

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoreftable/record: store "val2" hashes as static arrays
Patrick Steinhardt [Wed, 3 Jan 2024 06:22:34 +0000 (07:22 +0100)] 
reftable/record: store "val2" hashes as static arrays

Similar to the preceding commit, convert ref records of type "val2" to
store their object IDs in static arrays instead of allocating them for
every single record.

We're using the same benchmark as in the preceding commit, with `git
show-ref --quiet` in a repository with ~350k refs. This time around
though the effects aren't this huge. Before:

    HEAP SUMMARY:
        in use at exit: 21,163 bytes in 193 blocks
      total heap usage: 1,419,040 allocs, 1,418,847 frees, 62,153,868 bytes allocated

After:

    HEAP SUMMARY:
        in use at exit: 21,163 bytes in 193 blocks
      total heap usage: 1,410,148 allocs, 1,409,955 frees, 61,976,068 bytes allocated

This is because "val2"-type records are typically only stored for peeled
tags, and the number of annotated tags in the benchmark repository is
rather low. Still, it can be seen that this change leads to a reduction
of allocations overall, even if only a small one.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoreftable/record: store "val1" hashes as static arrays
Patrick Steinhardt [Wed, 3 Jan 2024 06:22:30 +0000 (07:22 +0100)] 
reftable/record: store "val1" hashes as static arrays

When reading ref records of type "val1", we store its object ID in an
allocated array. This results in an additional allocation for every
single ref record we read, which is rather inefficient especially when
iterating over refs.

Refactor the code to instead use an embedded array of `GIT_MAX_RAWSZ`
bytes. While this means that `struct ref_record` is bigger now, we
typically do not store all refs in an array anyway and instead only
handle a limited number of records at the same point in time.

Using `git show-ref --quiet` in a repository with ~350k refs this leads
to a significant drop in allocations. Before:

    HEAP SUMMARY:
        in use at exit: 21,098 bytes in 192 blocks
      total heap usage: 2,116,683 allocs, 2,116,491 frees, 76,098,060 bytes allocated

After:

    HEAP SUMMARY:
        in use at exit: 21,098 bytes in 192 blocks
      total heap usage: 1,419,031 allocs, 1,418,839 frees, 62,145,036 bytes allocated

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoreftable/record: constify some parts of the interface
Patrick Steinhardt [Wed, 3 Jan 2024 06:22:26 +0000 (07:22 +0100)] 
reftable/record: constify some parts of the interface

We're about to convert reftable records to stop storing their object IDs
as allocated hashes. Prepare for this refactoring by constifying some
parts of the interface that will be impacted by this.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoreftable/writer: fix index corruption when writing multiple indices
Patrick Steinhardt [Wed, 3 Jan 2024 06:22:21 +0000 (07:22 +0100)] 
reftable/writer: fix index corruption when writing multiple indices

Each reftable may contain multiple types of blocks for refs, objects and
reflog records, where each of these may have an index that makes it more
efficient to find the records. It was observed that the index for log
records can become corrupted under certain circumstances, where the
first entry of the index points into the object index instead of to the
log records.

As it turns out, this corruption can occur whenever we write a log index
as well as at least one additional index. Writing records and their index
is basically a two-step process:

  1. We write all blocks for the corresponding record. Each block that
     gets written is added to a list of blocks to index.

  2. Once all blocks were written we finish the section. If at least two
     blocks have been added to the list of blocks to index then we will
     now write the index for those blocks and flush it, as well.

When we have a very large number of blocks then we may decide to write a
multi-level index, which is why we also keep track of the list of the
index blocks in the same way as we previously kept track of the blocks
to index.

Now when we have finished writing all index blocks we clear the index
and flush the last block to disk. This is done in the wrong order though
because flushing the block to disk will re-add it to the list of blocks
to be indexed. The result is that the next section we are about to write
will have an entry in the list of blocks to index that points to the
last block of the preceding section's index, which will corrupt the log
index.

Fix this corruption by clearing the index after having written the last
block.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoreftable/stack: do not auto-compact twice in `reftable_stack_add()`
Patrick Steinhardt [Wed, 3 Jan 2024 06:22:17 +0000 (07:22 +0100)] 
reftable/stack: do not auto-compact twice in `reftable_stack_add()`

In 5c086453ff (reftable/stack: perform auto-compaction with
transactional interface, 2023-12-11), we fixed a bug where the
transactional interface to add changes to a reftable stack did not
perform auto-compaction by calling `reftable_stack_auto_compact()` in
`reftable_stack_addition_commit()`. While correct, this change may now
cause us to perform auto-compaction twice in the non-transactional
interface `reftable_stack_add()`:

  - It performs auto-compaction by itself.

  - It now transitively performs auto-compaction via the transactional
    interface.

Remove the first instance so that we only end up doing auto-compaction
once.

Reported-by: Han-Wen Nienhuys <hanwenn@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoreftable/stack: do not overwrite errors when compacting
Patrick Steinhardt [Wed, 3 Jan 2024 06:22:13 +0000 (07:22 +0100)] 
reftable/stack: do not overwrite errors when compacting

In order to compact multiple stacks we iterate through the merged ref
and log records. When there is any error either when reading the records
from the old merged table or when writing the records to the new table
then we break out of the respective loops. When breaking out of the loop
for the ref records though the error code will be overwritten, which may
cause us to inadvertently skip over bad ref records. In the worst case,
this can lead to a compacted stack that is missing records.

Fix the code by using `goto done` instead so that any potential error
codes are properly returned to the caller.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agot1006: prefer shell loop to awk for packed object sizes
René Scharfe [Wed, 3 Jan 2024 09:01:52 +0000 (04:01 -0500)] 
t1006: prefer shell loop to awk for packed object sizes

To compute the expected on-disk size of packed objects, we sort the
output of show-index by pack offset and then compute the difference
between adjacent entries using awk. This works but has a few readability
problems:

  1. Reading the index in pack order means don't find out the size of an
     oid's entry until we see the _next_ entry. So we have to save it to
     print later.

     We can instead iterate in reverse order, so we compute each oid's
     size as we see it.

  2. Since the awk invocation is inside a text_expect block, we can't
     easily use single-quotes to hold the script. So we use
     double-quotes, but then have to escape the dollar signs in the awk
     script.

     We can swap this out for a shell loop instead (which is made much
     easier by the first change).

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoThe fifth batch
Junio C Hamano [Tue, 2 Jan 2024 21:50:46 +0000 (13:50 -0800)] 
The fifth batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoMerge branch 'ps/pseudo-refs'
Junio C Hamano [Tue, 2 Jan 2024 21:51:30 +0000 (13:51 -0800)] 
Merge branch 'ps/pseudo-refs'

Assorted changes around pseudoref handling.

* ps/pseudo-refs:
  bisect: consistently write BISECT_EXPECTED_REV via the refdb
  refs: complete list of special refs
  refs: propagate errno when reading special refs fails
  wt-status: read HEAD and ORIG_HEAD via the refdb

5 months agoMerge branch 'jc/orphan-unborn'
Junio C Hamano [Tue, 2 Jan 2024 21:51:30 +0000 (13:51 -0800)] 
Merge branch 'jc/orphan-unborn'

Doc updates to clarify what an "unborn branch" means.

* jc/orphan-unborn:
  orphan/unborn: fix use of 'orphan' in end-user facing messages
  orphan/unborn: add to the glossary and use them consistently

5 months agoMerge branch 'rj/status-bisect-while-rebase'
Junio C Hamano [Tue, 2 Jan 2024 21:51:29 +0000 (13:51 -0800)] 
Merge branch 'rj/status-bisect-while-rebase'

"git status" is taught to show both the branch being bisected and
being rebased when both are in effect at the same time.

* rj/status-bisect-while-rebase:
  status: fix branch shown when not only bisecting

5 months agoMerge branch 'la/trailer-cleanups'
Junio C Hamano [Tue, 2 Jan 2024 21:51:29 +0000 (13:51 -0800)] 
Merge branch 'la/trailer-cleanups'

Code clean-up.

* la/trailer-cleanups:
  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

5 months agoMerge branch 'jc/retire-cas-opt-name-constant'
Junio C Hamano [Tue, 2 Jan 2024 21:51:29 +0000 (13:51 -0800)] 
Merge branch 'jc/retire-cas-opt-name-constant'

Code clean-up.

* jc/retire-cas-opt-name-constant:
  remote.h: retire CAS_OPT_NAME

5 months agoMerge branch 'rs/rebase-use-strvec-pushf'
Junio C Hamano [Tue, 2 Jan 2024 21:51:29 +0000 (13:51 -0800)] 
Merge branch 'rs/rebase-use-strvec-pushf'

Code clean-up.

* rs/rebase-use-strvec-pushf:
  rebase: use strvec_pushf() for format-patch revisions

5 months agoMerge branch 'sh/completion-with-reftable'
Junio C Hamano [Tue, 2 Jan 2024 21:51:28 +0000 (13:51 -0800)] 
Merge branch 'sh/completion-with-reftable'

Command line completion script (in contrib/) learned to work better
with the reftable backend.

* sh/completion-with-reftable:
  completion: support pseudoref existence checks for reftables
  completion: refactor existence checks for pseudorefs

5 months agot9500: write "extensions.refstorage" into config
Patrick Steinhardt [Fri, 29 Dec 2023 07:27:13 +0000 (08:27 +0100)] 
t9500: write "extensions.refstorage" into config

In t9500 we're writing a custom configuration that sets up gitweb. This
requires us to manually ensure that the repository format is configured
as required, including both the repository format version and
extensions. With the introduction of the "extensions.refStorage"
extension we need to update the test to also write this new one.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agobuiltin/clone: introduce `--ref-format=` value flag
Patrick Steinhardt [Fri, 29 Dec 2023 07:27:09 +0000 (08:27 +0100)] 
builtin/clone: introduce `--ref-format=` value flag

Introduce a new `--ref-format` value flag for git-clone(1) that allows
the user to specify the ref format that is to be used for a newly
initialized repository.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agobuiltin/init: introduce `--ref-format=` value flag
Patrick Steinhardt [Fri, 29 Dec 2023 07:27:04 +0000 (08:27 +0100)] 
builtin/init: introduce `--ref-format=` value flag

Introduce a new `--ref-format` value flag for git-init(1) that allows
the user to specify the ref format that is to be used for a newly
initialized repository.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agobuiltin/rev-parse: introduce `--show-ref-format` flag
Patrick Steinhardt [Fri, 29 Dec 2023 07:27:00 +0000 (08:27 +0100)] 
builtin/rev-parse: introduce `--show-ref-format` flag

Introduce a new `--show-ref-format` to git-rev-parse(1) that causes it
to print the ref format used by a repository.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agot: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar
Patrick Steinhardt [Fri, 29 Dec 2023 07:26:56 +0000 (08:26 +0100)] 
t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar

Introduce a new GIT_TEST_DEFAULT_REF_FORMAT environment variable that
lets developers run the test suite with a different default ref format
without impacting the ref format used by non-test Git invocations. This
is modeled after GIT_TEST_DEFAULT_OBJECT_FORMAT, which does the same
thing for the repository's object format.

Adapt the setup of the `REFFILES` test prerequisite to be conditionally
set based on the default ref format.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agosetup: introduce GIT_DEFAULT_REF_FORMAT envvar
Patrick Steinhardt [Fri, 29 Dec 2023 07:26:52 +0000 (08:26 +0100)] 
setup: introduce GIT_DEFAULT_REF_FORMAT envvar

Introduce a new GIT_DEFAULT_REF_FORMAT environment variable that lets
users control the default ref format used by both git-init(1) and
git-clone(1). This is modeled after GIT_DEFAULT_OBJECT_FORMAT, which
does the same thing for the repository's object format.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agosetup: introduce "extensions.refStorage" extension
Patrick Steinhardt [Fri, 29 Dec 2023 07:26:47 +0000 (08:26 +0100)] 
setup: introduce "extensions.refStorage" extension

Introduce a new "extensions.refStorage" extension that allows us to
specify the ref storage format used by a repository. For now, the only
supported format is the "files" format, but this list will likely soon
be extended to also support the upcoming "reftable" format.

There have been discussions on the Git mailing list in the past around
how exactly this extension should look like. One alternative [1] that
was discussed was whether it would make sense to model the extension in
such a way that backends are arbitrarily stackable. This would allow for
a combined value of e.g. "loose,packed-refs" or "loose,reftable", which
indicates that new refs would be written via "loose" files backend and
compressed into "packed-refs" or "reftable" backends, respectively.

It is arguable though whether this flexibility and the complexity that
it brings with it is really required for now. It is not foreseeable that
there will be a proliferation of backends in the near-term future, and
the current set of existing formats and formats which are on the horizon
can easily be configured with the much simpler proposal where we have a
single value, only.

Furthermore, if we ever see that we indeed want to gain the ability to
arbitrarily stack the ref formats, then we can adapt the current
extension rather easily. Given that Git clients will refuse any unknown
value for the "extensions.refStorage" extension they would also know to
ignore a stacked "loose,packed-refs" in the future.

So let's stick with the easy proposal for the time being and wire up the
extension.

[1]: <pull.1408.git.1667846164.gitgitgadget@gmail.com>

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agosetup: set repository's formats on init
Patrick Steinhardt [Fri, 29 Dec 2023 07:26:43 +0000 (08:26 +0100)] 
setup: set repository's formats on init

The proper hash algorithm and ref storage format that will be used for a
newly initialized repository will be figured out in `init_db()` via
`validate_hash_algorithm()` and `validate_ref_storage_format()`. Until
now though, we never set up the hash algorithm or ref storage format of
`the_repository` accordingly.

There are only two callsites of `init_db()`, one in git-init(1) and one
in git-clone(1). The former function doesn't care for the formats to be
set up properly because it never access the repository after calling the
function in the first place.

For git-clone(1) it's a different story though, as we call `init_db()`
before listing remote refs. While we do indeed have the wrong hash
function in `the_repository` when `init_db()` sets up a non-default
object format for the repository, it never mattered because we adjust
the hash after learning about the remote's hash function via the listed
refs.

So the current state is correct for the hash algo, but it's not for the
ref storage format because git-clone(1) wouldn't know to set it up
properly. But instead of adjusting only the `ref_storage_format`, set
both the hash algo and the ref storage format so that `the_repository`
is in the correct state when `init_db()` exits. This is fine as we will
adjust the hash later on anyway and makes it easier to reason about the
end state of `the_repository`.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agosetup: start tracking ref storage format
Patrick Steinhardt [Fri, 29 Dec 2023 07:26:39 +0000 (08:26 +0100)] 
setup: start tracking ref storage format

In order to discern which ref storage format a repository is supposed to
use we need to start setting up and/or discovering the format. This
needs to happen in two separate code paths.

  - The first path is when we create a repository via `init_db()`. When
    we are re-initializing a preexisting repository we need to retain
    the previously used ref storage format -- if the user asked for a
    different format then this indicates an error and we error out.
    Otherwise we either initialize the repository with the format asked
    for by the user or the default format, which currently is the
    "files" backend.

  - The second path is when discovering repositories, where we need to
    read the config of that repository. There is not yet any way to
    configure something other than the "files" backend, so we can just
    blindly set the ref storage format to this backend.

Wire up this logic so that we have the ref storage format always readily
available when needed. As there is only a single backend and because it
is not configurable we cannot yet verify that this tracking works as
expected via tests, but tests will be added in subsequent commits. To
countermand this ommission now though, raise a BUG() in case the ref
storage format is not set up properly in `ref_store_init()`.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agorefs: refactor logic to look up storage backends
Patrick Steinhardt [Fri, 29 Dec 2023 07:26:34 +0000 (08:26 +0100)] 
refs: refactor logic to look up storage backends

In order to look up ref storage backends, we're currently using a linked
list of backends, where each backend is expected to set up its `next`
pointer to the next ref storage backend. This is kind of a weird setup
as backends need to be aware of other backends without much of a reason.

Refactor the code so that the array of backends is centrally defined in
"refs.c", where each backend is now identified by an integer constant.
Expose functions to translate from those integer constants to the name
and vice versa, which will be required by subsequent patches.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoworktree: skip reading HEAD when repairing worktrees
Patrick Steinhardt [Fri, 29 Dec 2023 07:26:30 +0000 (08:26 +0100)] 
worktree: skip reading HEAD when repairing worktrees

When calling `git init --separate-git-dir=<new-path>` on a preexisting
repository, we move the Git directory of that repository to the new path
specified by the user. If there are worktrees present in the repository,
we need to repair the worktrees so that their gitlinks point to the new
location of the repository.

This repair logic will load repositories via `get_worktrees()`, which
will enumerate up and initialize all worktrees. Part of initialization
is logic that we resolve their respective worktree HEADs, even though
that information may not actually be needed in the end by all callers.

Although not a problem presently with the file-based reference backend,
it will become a problem with the upcoming reftable backend. In the
context of git-init(1) we do not have a fully-initialized repository set
up via `setup_git_directory()` or friends. Consequently, we do not know
about the repository format when `repair_worktrees()` is called, and
properly setting up all parts of the repositroy in `init_db()` before we
try to repair worktrees is not an easy task. With the introduction of
the reftable backend, we would ultimately try to look up the worktree
HEADs before we have figured out the reference format, which does not
work.

We do not require the worktree HEADs at all to repair worktrees. So
let's fix this issue by skipping over the step that reads them.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agot: introduce DEFAULT_REPO_FORMAT prereq
Patrick Steinhardt [Fri, 29 Dec 2023 07:26:26 +0000 (08:26 +0100)] 
t: introduce DEFAULT_REPO_FORMAT prereq

A limited number of tests require repositories to have the default
repository format or otherwise they would fail to run, e.g. because they
fail to detect the correct hash function. While the hash function is the
only extension right now that creates problems like this, we are about
to add a second extension for the ref format.

Introduce a new DEFAULT_REPO_FORMAT prereq that can easily be amended
whenever we add new format extensions. Next to making any such changes
easier on us, the prerequisite's name should also help to clarify the
intent better.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoattr: add builtin objectmode values support
Joanna Wang [Thu, 16 Nov 2023 05:44:37 +0000 (05:44 +0000)] 
attr: add builtin objectmode values support

Gives all paths builtin objectmode values based on the paths' modes
(one of 100644, 100755, 120000, 040000, 160000). Users may use
this feature to filter by file types. For example a pathspec such as
':(attr:builtin_objectmode=160000)' could filter for submodules without
needing to have `builtin_objectmode=160000` to be set in .gitattributes
for every submodule path.

These values are also reflected in `git check-attr` results.
If the git_attr_direction is set to GIT_ATTR_INDEX or GIT_ATTR_CHECKIN
and a path is not found in the index, the value will be unspecified.

This patch also reserves the builtin_* attribute namespace for objectmode
and any future builtin attributes. Any user defined attributes using this
reserved namespace will result in a warning. This is a breaking change for
any existing builtin_* attributes.
Pathspecs with some builtin_* attribute name (excluding builtin_objectmode)
will behave like any attribute where there are no user specified values.

Signed-off-by: Joanna Wang <jojwang@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agomem-pool: simplify alignment calculation
René Scharfe [Sun, 24 Dec 2023 17:02:04 +0000 (18:02 +0100)] 
mem-pool: simplify alignment calculation

Use DIV_ROUND_UP in mem_pool_alloc() to round the allocation length to
the next multiple of GIT_MAX_ALIGNMENT instead of twiddling bits
explicitly.  This is shorter and clearer, to the point that we no longer
need the comment that explains what's being calculated.

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agomem-pool: fix big allocations
René Scharfe [Thu, 28 Dec 2023 19:19:06 +0000 (20:19 +0100)] 
mem-pool: fix big allocations

Memory pool allocations that require a new block and would fill at
least half of it are handled specially.  Before 158dfeff3d (mem-pool:
add life cycle management functions, 2018-07-02) they used to be
allocated outside of the pool.  This patch made mem_pool_alloc() create
a bespoke block instead, to allow releasing it when the pool gets
discarded.

Unfortunately mem_pool_alloc() returns a pointer to the start of such a
bespoke block, i.e. to the struct mp_block at its top.  When the caller
writes to it, the management information gets corrupted.  This affects
mem_pool_discard() and -- if there are no other blocks in the pool --
also mem_pool_alloc().

Return the payload pointer of bespoke blocks, just like for smaller
allocations, to protect the management struct.

Also update next_free to mark the block as full.  This is only strictly
necessary for the first allocated block, because subsequent ones are
inserted after the current block and never considered for further
allocations, but it's easier to just do it in all cases.

Add a basic unit test to demonstrate the issue by using
mem_pool_calloc() with a tiny block size, which forces the creation of a
bespoke block.

Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoSubmittingPatches: hyphenate non-ASCII
Josh Soref [Thu, 28 Dec 2023 04:55:24 +0000 (04:55 +0000)] 
SubmittingPatches: hyphenate non-ASCII

Git documentation does this with the exception of ancient release notes.

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoSubmittingPatches: clarify GitHub artifact format
Josh Soref [Thu, 28 Dec 2023 04:55:23 +0000 (04:55 +0000)] 
SubmittingPatches: clarify GitHub artifact format

GitHub wraps artifacts generated by workflows in a .zip file.

Internally, workflows can package anything they like in them.

A recently generated failure artifact had the form:

windows-artifacts.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
 76001695  12-19-2023 01:35   artifacts.tar.gz
 11005650  12-19-2023 01:35   tracked.tar.gz
---------                     -------
 87007345                     2 files

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoSubmittingPatches: clarify GitHub visual
Josh Soref [Thu, 28 Dec 2023 04:55:22 +0000 (04:55 +0000)] 
SubmittingPatches: clarify GitHub visual

GitHub has two general forms for its states, sometimes they're a simple
colored object (e.g. green check or red x), and sometimes there's also a
colored container (e.g. green box or red circle) which contains that
object (e.g. check or x).

That's a lot of words to try to describe things, but in general, the key
for a failure is that it's recognized as an `x` and that it's associated
with the color red -- the color of course is problematic for people who
are red-green color-blind, but that's why they are paired with distinct
shapes.

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoSubmittingPatches: provide tag naming advice
Josh Soref [Thu, 28 Dec 2023 04:55:21 +0000 (04:55 +0000)] 
SubmittingPatches: provide tag naming advice

Current statistics show a strong preference to only capitalize the first
letter in a hyphenated tag, but that some guidance would be helpful:

git log |
  perl -ne 'next unless /^\s+(?:Signed-[oO]ff|Acked)-[bB]y:/;
    s/^\s+//;s/:.*/:/;print'|
  sort|uniq -c|sort -n
   2 Signed-off-By:
   4 Signed-Off-by:
  22 Acked-By:
  47 Signed-Off-By:
2202 Acked-by:
95315 Signed-off-by:

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoSubmittingPatches: update extra tags list
Josh Soref [Thu, 28 Dec 2023 04:55:20 +0000 (04:55 +0000)] 
SubmittingPatches: update extra tags list

Add items with at least 100 uses in the past three years:
- Co-authored-by
- Helped-by
- Mentored-by
- Suggested-by

git log --since=3.years|
  perl -ne 'next unless /^\s+[A-Z][a-z]+-\S+:/;s/^\s+//;s/:.*/:/;print'|
  sort|uniq -c|sort -n|grep '[0-9][0-9] '
  14 Based-on-patch-by:
  14 Original-patch-by:
  17 Tested-by:
 100 Suggested-by:
 121 Co-authored-by:
 163 Mentored-by:
 274 Reported-by:
 290 Acked-by:
 450 Helped-by:
 602 Reviewed-by:
14111 Signed-off-by:

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoSubmittingPatches: discourage new trailers
Josh Soref [Thu, 28 Dec 2023 04:55:19 +0000 (04:55 +0000)] 
SubmittingPatches: discourage new trailers

There seems to be consensus amongst the core Git community on a working
set of common trailers, and there are non-trivial costs to people
inventing new trailers (research to discover what they mean/how they
differ from existing trailers) such that inventing new ones is generally
unwarranted and not something to be recommended to new contributors.

Suggested-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoSubmittingPatches: drop ref to "What's in git.git"
Josh Soref [Thu, 28 Dec 2023 04:55:18 +0000 (04:55 +0000)] 
SubmittingPatches: drop ref to "What's in git.git"

"What's in git.git" was last seen in 2010:
  https://lore.kernel.org/git/?q=%22what%27s+in+git.git%22
  https://lore.kernel.org/git/7vaavikg72.fsf@alter.siamese.dyndns.org/

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoCodingGuidelines: write punctuation marks
Josh Soref [Thu, 28 Dec 2023 04:55:17 +0000 (04:55 +0000)] 
CodingGuidelines: write punctuation marks

- Match style in Release Notes

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoCodingGuidelines: move period inside parentheses
Josh Soref [Thu, 28 Dec 2023 04:55:16 +0000 (04:55 +0000)] 
CodingGuidelines: move period inside parentheses

The contents within parenthesis should be omittable without resulting
in broken text.

Eliding the parenthesis left a period to end a run without any content.

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoThe fourth batch
Junio C Hamano [Wed, 27 Dec 2023 22:51:46 +0000 (14:51 -0800)] 
The fourth batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoMerge branch 'ps/clone-into-reftable-repository'
Junio C Hamano [Wed, 27 Dec 2023 22:52:28 +0000 (14:52 -0800)] 
Merge branch 'ps/clone-into-reftable-repository'

"git clone" has been prepared to allow cloning a repository with
non-default hash function into a repository that uses the reftable
backend.

* ps/clone-into-reftable-repository:
  builtin/clone: create the refdb with the correct object format
  builtin/clone: skip reading HEAD when retrieving remote
  builtin/clone: set up sparse checkout later
  builtin/clone: fix bundle URIs with mismatching object formats
  remote-curl: rediscover repository when fetching refs
  setup: allow skipping creation of the refdb
  setup: extract function to create the refdb

5 months agoMerge branch 'rs/t6300-compressed-size-fix'
Junio C Hamano [Wed, 27 Dec 2023 22:52:27 +0000 (14:52 -0800)] 
Merge branch 'rs/t6300-compressed-size-fix'

Test fix.

* rs/t6300-compressed-size-fix:
  t6300: avoid hard-coding object sizes

5 months agoMerge branch 'jx/fetch-atomic-error-message-fix'
Junio C Hamano [Wed, 27 Dec 2023 22:52:27 +0000 (14:52 -0800)] 
Merge branch 'jx/fetch-atomic-error-message-fix'

"git fetch --atomic" issued an unnecessary empty error message,
which has been corrected.

* jx/fetch-atomic-error-message-fix:
  fetch: no redundant error message for atomic fetch
  t5574: test porcelain output of atomic fetch

5 months agoMerge branch 'rs/c99-stdbool-test-balloon'
Junio C Hamano [Wed, 27 Dec 2023 22:52:27 +0000 (14:52 -0800)] 
Merge branch 'rs/c99-stdbool-test-balloon'

Test balloon to use C99 "bool" type from <stdbool.h>.

* rs/c99-stdbool-test-balloon:
  git-compat-util: convert skip_{prefix,suffix}{,_mem} to bool

5 months agoMerge branch 'sp/test-i18ngrep'
Junio C Hamano [Wed, 27 Dec 2023 22:52:27 +0000 (14:52 -0800)] 
Merge branch 'sp/test-i18ngrep'

Error message fix in the test framework.

* sp/test-i18ngrep:
  test-lib-functions.sh: fix test_grep fail message wording

5 months agoMerge branch 'jc/doc-misspelt-refs-fix'
Junio C Hamano [Wed, 27 Dec 2023 22:52:26 +0000 (14:52 -0800)] 
Merge branch 'jc/doc-misspelt-refs-fix'

Doc update.

* jc/doc-misspelt-refs-fix:
  doc: format.notes specify a ref under refs/notes/ hierarchy

5 months agoMerge branch 'jc/doc-most-refs-are-not-that-special'
Junio C Hamano [Wed, 27 Dec 2023 22:52:26 +0000 (14:52 -0800)] 
Merge branch 'jc/doc-most-refs-are-not-that-special'

Doc updates.

* jc/doc-most-refs-are-not-that-special:
  docs: MERGE_AUTOSTASH is not that special
  docs: AUTO_MERGE is not that special
  refs.h: HEAD is not that special
  git-bisect.txt: BISECT_HEAD is not that special
  git.txt: HEAD is not that special

5 months agoMerge branch 'es/add-doc-list-short-form-of-all-in-synopsis'
Junio C Hamano [Wed, 27 Dec 2023 22:52:26 +0000 (14:52 -0800)] 
Merge branch 'es/add-doc-list-short-form-of-all-in-synopsis'

Doc update.

* es/add-doc-list-short-form-of-all-in-synopsis:
  git-add.txt: add missing short option -A to synopsis

5 months agoMerge branch 'jk/mailinfo-iterative-unquote-comment'
Junio C Hamano [Wed, 27 Dec 2023 22:52:26 +0000 (14:52 -0800)] 
Merge branch 'jk/mailinfo-iterative-unquote-comment'

The code to parse the From e-mail header has been updated to avoid
recursion.

* jk/mailinfo-iterative-unquote-comment:
  mailinfo: avoid recursion when unquoting From headers
  t5100: make rfc822 comment test more careful

5 months agoMerge branch 'ps/chainlint-self-check-update'
Junio C Hamano [Wed, 27 Dec 2023 22:52:25 +0000 (14:52 -0800)] 
Merge branch 'ps/chainlint-self-check-update'

Test framework update.

* ps/chainlint-self-check-update:
  tests: adjust whitespace in chainlint expectations

5 months agoMerge branch 'rs/show-ref-incompatible-options'
Junio C Hamano [Wed, 27 Dec 2023 22:52:25 +0000 (14:52 -0800)] 
Merge branch 'rs/show-ref-incompatible-options'

Code clean-up for sanity checking of command line options for "git
show-ref".

* rs/show-ref-incompatible-options:
  show-ref: use die_for_incompatible_opt3()

5 months agoMerge branch 'ps/reftable-fixes'
Junio C Hamano [Wed, 27 Dec 2023 22:52:25 +0000 (14:52 -0800)] 
Merge branch 'ps/reftable-fixes'

Bunch of small fix-ups to the reftable code.

* ps/reftable-fixes:
  reftable/block: reuse buffer to compute record keys
  reftable/block: introduce macro to initialize `struct block_iter`
  reftable/merged: reuse buffer to compute record keys
  reftable/stack: fix use of unseeded randomness
  reftable/stack: fix stale lock when dying
  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

5 months agoMerge branch 'jc/diff-cached-fsmonitor-fix'
Junio C Hamano [Wed, 27 Dec 2023 22:52:25 +0000 (14:52 -0800)] 
Merge branch 'jc/diff-cached-fsmonitor-fix'

The optimization based on fsmonitor in the "diff --cached"
codepath is resurrected with the "fake-lstat" introduced earlier.

* jc/diff-cached-fsmonitor-fix:
  diff-lib: fix check_removed() when fsmonitor is active

5 months agoMerge branch 'jc/fake-lstat'
Junio C Hamano [Wed, 27 Dec 2023 22:52:24 +0000 (14:52 -0800)] 
Merge branch 'jc/fake-lstat'

A new helper to let us pretend that we called lstat() when we know
our cache_entry is up-to-date via fsmonitor.

* jc/fake-lstat:
  cache: add fake_lstat()

5 months agoMerge branch 'jk/mailinfo-oob-read-fix'
Junio C Hamano [Wed, 27 Dec 2023 22:52:24 +0000 (14:52 -0800)] 
Merge branch 'jk/mailinfo-oob-read-fix'

OOB read fix.

* jk/mailinfo-oob-read-fix:
  mailinfo: fix out-of-bounds memory reads in unquote_quoted_pair()

5 months agoMerge branch 'jc/checkout-B-branch-in-use'
Junio C Hamano [Wed, 27 Dec 2023 22:52:24 +0000 (14:52 -0800)] 
Merge branch 'jc/checkout-B-branch-in-use'

"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.

* jc/checkout-B-branch-in-use:
  checkout: forbid "-B <branch>" from touching a branch used elsewhere
  checkout: refactor die_if_checked_out() caller

5 months agosparse-checkout: use default patterns for 'set' only !stdin
Junio C Hamano [Thu, 21 Dec 2023 06:59:24 +0000 (22:59 -0800)] 
sparse-checkout: use default patterns for 'set' only !stdin

"git sparse-checkout set ---no-cone" uses default patterns when none
is given from the command line, but it should do so ONLY when
--stdin is not being used.  Right now, add_patterns_from_input()
called when reading from the standard input is sloppy and does not
check if there are extra command line parameters that the command
will silently ignore, but that will change soon and not setting this
unnecessary and unused default patterns start to matter when it gets
fixed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agosparse-checkout: be consistent with end of options markers
Elijah Newren [Tue, 26 Dec 2023 19:39:22 +0000 (19:39 +0000)] 
sparse-checkout: be consistent with end of options markers

93851746 (parse-options: decouple "--end-of-options" and "--",
2023-12-06) updated the world order to make callers of parse-options
that set PARSE_OPT_KEEP_UNKNOWN_OPT responsible for deciding what to
do with "--end-of-options" they may see after parse_options() returns.

This made a previous bug in sparse-checkout more visible; namely,
that

  git sparse-checkout [add|set] --[no-]cone --end-of-options ...

would simply treat "--end-of-options" as one of the paths to include in
the sparse-checkout.  But this was already problematic before; namely,

  git sparse-checkout [add|set| --[no-]cone --sikp-checks ...

would not give an error on the mis-typed "--skip-checks" but instead
simply treat "--sikp-checks" as a path or pattern to include in the
sparse-checkout, which is highly unfriendly.

This behavior began when the command was converted to parse-options in
7bffca95ea (sparse-checkout: add '--stdin' option to set subcommand,
2019-11-21).  Back then it was just called KEEP_UNKNOWN. Later it was
renamed to KEEP_UNKNOWN_OPT in 99d86d60e5 (parse-options:
PARSE_OPT_KEEP_UNKNOWN only applies to --options, 2022-08-19) to clarify
that it was only about dashed options; we always keep non-option
arguments.  Looking at that original patch, both Peff and I think that
the author was simply confused about the mis-named option, and really
just wanted to keep the non-option arguments.  We never should have used
the flag all along (and the other cases were cargo-culted within the
file).

Remove the erroneous PARSE_OPT_KEEP_UNKNOWN_OPT flag now to fix this
bug.  Note that this does mean that anyone who might have been using

  git sparse-checkout [add|set] [--[no-]cone] --foo --bar

to request paths or patterns '--foo' and '--bar' will now have to use

  git sparse-checkout [add|set] [--[no-]cone] -- --foo --bar

That makes sparse-checkout more consistent with other git commands,
provides users much friendlier error messages and behavior, and is
consistent with the all-caps warning in git-sparse-checkout.txt that
this command "is experimental...its behavior...will likely change".  :-)

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agotreewide: remove unnecessary includes in source files
Elijah Newren [Sat, 23 Dec 2023 17:15:00 +0000 (17:15 +0000)] 
treewide: remove unnecessary includes in source files

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agotreewide: add direct includes currently only pulled in transitively
Elijah Newren [Sat, 23 Dec 2023 17:14:59 +0000 (17:14 +0000)] 
treewide: add direct includes currently only pulled in transitively

The next commit will remove a bunch of unnecessary includes, but to do
so, we need some of the lower level direct includes that files rely on
to be explicitly specified.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agotrace2/tr2_tls.h: remove unnecessary include
Elijah Newren [Sat, 23 Dec 2023 17:14:58 +0000 (17:14 +0000)] 
trace2/tr2_tls.h: remove unnecessary include

The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though.  Have those
source files explicitly include the headers they need.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agosubmodule-config.h: remove unnecessary include
Elijah Newren [Sat, 23 Dec 2023 17:14:57 +0000 (17:14 +0000)] 
submodule-config.h: remove unnecessary include

The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though.  Have those
source files explicitly include the headers they need.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agopkt-line.h: remove unnecessary include
Elijah Newren [Sat, 23 Dec 2023 17:14:56 +0000 (17:14 +0000)] 
pkt-line.h: remove unnecessary include

The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though.  Have those
source files explicitly include the headers they need.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoline-log.h: remove unnecessary include
Elijah Newren [Sat, 23 Dec 2023 17:14:55 +0000 (17:14 +0000)] 
line-log.h: remove unnecessary include

The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though.  Have those
source files explicitly include the headers they need.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agohttp.h: remove unnecessary include
Elijah Newren [Sat, 23 Dec 2023 17:14:54 +0000 (17:14 +0000)] 
http.h: remove unnecessary include

The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though.  Have those
source files explicitly include the headers they need.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agofsmonitor--daemon.h: remove unnecessary includes
Elijah Newren [Sat, 23 Dec 2023 17:14:53 +0000 (17:14 +0000)] 
fsmonitor--daemon.h: remove unnecessary includes

The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though.  Have those
source files explicitly include the headers they need.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoblame.h: remove unnecessary includes
Elijah Newren [Sat, 23 Dec 2023 17:14:52 +0000 (17:14 +0000)] 
blame.h: remove unnecessary includes

The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though.  Have those
source files explicitly include the headers they need.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoarchive.h: remove unnecessary include
Elijah Newren [Sat, 23 Dec 2023 17:14:51 +0000 (17:14 +0000)] 
archive.h: remove unnecessary include

The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though.  Have those
source files explicitly include the headers they need.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agotreewide: remove unnecessary includes in source files
Elijah Newren [Sat, 23 Dec 2023 17:14:50 +0000 (17:14 +0000)] 
treewide: remove unnecessary includes in source files

Each of these were checked with
   gcc -E -I. ${SOURCE_FILE} | grep ${HEADER_FILE}
to ensure that removing the direct inclusion of the header actually
resulted in that header no longer being included at all (i.e. that
no other header pulled it in transitively).

...except for a few cases where we verified that although the header
was brought in transitively, nothing from it was directly used in
that source file.  These cases were:
  * builtin/credential-cache.c
  * builtin/pull.c
  * builtin/send-pack.c

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agotreewide: remove unnecessary includes from header files
Elijah Newren [Sat, 23 Dec 2023 17:14:49 +0000 (17:14 +0000)] 
treewide: remove unnecessary includes from header files

There are three kinds of unnecessary includes:
  * includes which aren't directly needed, but which include some other
    forgotten include
  * includes which could be replaced by a simple forward declaration of
    some structs
  * includes which aren't needed at all

Remove the third kind of include.  Subsequent commits (and a subsequent
series) will work on removing some of the other kinds of includes.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agofast-import: use mem_pool_calloc()
René Scharfe [Tue, 26 Dec 2023 08:17:45 +0000 (09:17 +0100)] 
fast-import: use mem_pool_calloc()

Use mem_pool_calloc() to get a zeroed buffer instead of zeroing it
ourselves.  This makes the code clearer and less repetitive.

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agot1006: add tests for %(objectsize:disk)
Jeff King [Thu, 21 Dec 2023 09:47:22 +0000 (04:47 -0500)] 
t1006: add tests for %(objectsize:disk)

Back when we added this placeholder in a4ac106178 (cat-file: add
%(objectsize:disk) format atom, 2013-07-10), there were no tests,
claiming "[...]the exact numbers returned are volatile and subject to
zlib and packing decisions".

But we can use a little shell hackery to get the expected numbers
ourselves. To a certain degree this is just re-implementing what Git is
doing under the hood, but it is still worth doing. It makes sure we
exercise the %(objectsize:disk) code at all, and having the two
implementations agree gives us more confidence.

Note that our shell code assumes that no object appears twice (either in
two packs, or as both loose and packed), as then the results really are
undefined. That's OK for our purposes, and the test will notice if that
assumption is violated (the shell version would produce duplicate lines
that Git's output does not have).

Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoarchive: "--list" does not take further options
Junio C Hamano [Thu, 21 Dec 2023 18:13:58 +0000 (10:13 -0800)] 
archive: "--list" does not take further options

"git archive --list blah" should notice an extra command line
parameter that goes unused.  Make it so.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoMerge branch 'jk/end-of-options' into jc/sparse-checkout-set-add-end-of-options
Junio C Hamano [Thu, 21 Dec 2023 05:49:33 +0000 (21:49 -0800)] 
Merge branch 'jk/end-of-options' into jc/sparse-checkout-set-add-end-of-options

* jk/end-of-options:
  parse-options: decouple "--end-of-options" and "--"

5 months agoDocumentation/git-merge.txt: use backticks for command wrapping
Michael Lohmann [Wed, 20 Dec 2023 19:53:42 +0000 (20:53 +0100)] 
Documentation/git-merge.txt: use backticks for command wrapping

As René found in the guidance from CodingGuidelines:

   Literal examples (e.g. use of command-line options, command names,
   branch names, URLs, pathnames (files and directories), configuration
   and environment variables) must be typeset in monospace (i.e. wrapped
   with backticks)

So all instances of single and double quotes for wraping said examples
were replaced with simple backticks.

Suggested-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agoDocumentation/git-merge.txt: fix reference to synopsis
Michael Lohmann [Wed, 20 Dec 2023 21:35:34 +0000 (22:35 +0100)] 
Documentation/git-merge.txt: fix reference to synopsis

437591a9d738 combined the synopsis of "The second syntax" (meaning `git
merge --abort`) and "The third syntax" (for `git merge --continue`) into
this single line:

       git merge (--continue | --abort | --quit)

but it was still referred to when describing the preconditions that have
to be fulfilled to run the respective actions. In other words:
References by number are no longer valid after a merge of some of the
synopses.

Also the previous version of the documentation did not acknowledge that
`--no-commit` would result in the precondition being fulfilled (thanks
to Elijah Newren and Junio C Hamano for pointing that out).

This change also groups `--abort` and `--continue` together when
explaining the prerequisites in order to avoid duplication.

Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agotrailer: use offsets for trailer_start/trailer_end
Linus Arver [Fri, 20 Oct 2023 19:01:35 +0000 (19:01 +0000)] 
trailer: use offsets for trailer_start/trailer_end

Previously these fields in the trailer_info struct were of type "const
char *" and pointed to positions in the input string directly (to the
start and end positions of the trailer block).

Use offsets to make the intended usage less ambiguous. We only need to
reference the input string in format_trailer_info(), so update that
function to take a pointer to the input.

While we're at it, rename trailer_start to trailer_block_start to be
more explicit about these offsets (that they are for the entire trailer
block including other trailers). Ditto for trailer_end.

Reported-by: Glen Choo <glencbz@gmail.com>
Signed-off-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 months agotrailer: find the end of the log message
Linus Arver [Fri, 20 Oct 2023 19:01:34 +0000 (19:01 +0000)] 
trailer: find the end of the log message

Previously, trailer_info_get() computed the trailer block end position
by

(1) checking for the opts->no_divider flag and optionally calling
    find_patch_start() to find the "patch start" location (patch_start), and
(2) calling find_trailer_end() to find the end of the trailer block
    using patch_start as a guide, saving the return value into
    "trailer_end".

The logic in (1) was awkward because the variable "patch_start" is
misleading if there is no patch in the input. The logic in (2) was
misleading because it could be the case that no trailers are in the
input (yet we are setting a "trailer_end" variable before even searching
for trailers, which happens later in find_trailer_start()). The name
"find_trailer_end" was misleading because that function did not look for
any trailer block itself --- instead it just computed the end position
of the log message in the input where the end of the trailer block (if
it exists) would be (because trailer blocks must always come after the
end of the log message).

Combine the logic in (1) and (2) together into find_patch_start() by
renaming it to find_end_of_log_message(). The end of the log message is
the starting point which find_trailer_start() needs to start searching
backward to parse individual trailers (if any).

Helped-by: Jonathan Tan <jonathantanmy@google.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>