[pull] master from git:master#229
Merged
Merged
Conversation
Enable ENABLE_ADVICE_PULL for push-branch comparisons too, not just the upstream entry, so the "use git pull" hint prints when the local branch is behind its push branch. Spell out "git pull <remote> <branch>" so running the suggested command actually pulls the ref the user was told about; plain "git pull" would fetch the upstream instead. Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's simpler and more efficient to just use `git init client` instead of `mkdir client && git -C client init`. So let's replace the latter with the former. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The last argument of url_normalize_1() is `char allow_globs` but it is used as a boolean, not as a char. Let's convert it to a `bool`, and while at it convert the two calls to url_normalize_1() so they pass 'true' or 'false' instead of '1' or '0'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a following commit, we will need to normalize a URL glob pattern (which may contain '*' in the host portion) and extract its component offsets (host, path, etc.) for separate matching. Let's export a dedicated helper function url_normalize_pattern() for that purpose. It works like url_normalize(), but passes allow_globs=true to the internal url_normalize_1(), so that '*' characters in the host are accepted rather than rejected. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a following commit, we will store promisor remote information under a remote name different than the one the server advertised. To prepare for this change, let's add a new 'char *local_name' member to 'struct promisor_info', and let's update the related functions. While at it, let's also add a small promisor_info_local_name() helper that returns `local_name` when set, `name` otherwise, and let's use this small helper in promisor_store_advertised_fields() and in the post-loop of filter_promisor_remote() so that lookups against the local repo configuration use the right name. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "promisor-remote" protocol capability allows servers to advertise promisor remotes, but doesn't allow these remotes to be automatically configured on the client. Let's introduce a new `promisor.acceptFromServerUrl` config variable which contains a glob pattern, so that advertised remotes with a URL matching that pattern will be automatically configured. The glob pattern can optionally be prefixed with a remote name which will be used as the name of the new local remote. For now though, let's only introduce the functions to read and validate the glob patterns and the optional prefixes. Checking if the URLs of the advertised remotes match the glob patterns and taking the appropriate action is left for a following commit. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
A previous commit introduced the `promisor.acceptFromServerUrl` config
variable along with the machinery to parse and validate the URL glob
patterns and optional remote name prefixes it contains. However, these
URL patterns are not yet tied into the client's acceptance logic.
When a promisor remote is already configured locally, its fields (like
authentication tokens) may occasionally need to be refreshed by the
server. If `promisor.acceptFromServer` is set to the secure default
("None"), these updates are rejected, potentially causing future
fetches to fail.
To enable such targeted updates for trusted URLs, let's use the URL
patterns from `promisor.acceptFromServerUrl` as an additional URL
based allowlist.
Concretely, let's check the advertised URLs against the URL glob
patterns by introducing a new small helper function called
url_matches_accept_list(), which iterates over the glob patterns and
returns the first matching allowed_url entry (or NULL).
The URL matching is done component by component: scheme and port are
compared exactly, the host and path are matched with wildmatch().
Before matching, the advertised URL is passed through url_normalize()
so that case variations in the scheme/host, percent-encoding tricks,
and ".." path segments cannot bypass the allowlist.
The username and password components of the URL are intentionally
ignored during matching to allow servers to rotate them, though using
the 'token' field of the capability is preferred over embedding
credentials in the URL.
Let's then use this helper in should_accept_remote() so that a known
remote whose URL matches the allowlist is accepted.
To prepare for this new logic, let's also:
- Add an 'accept_urls' parameter to should_accept_remote().
- Replace the BUG() guard in the ACCEPT_KNOWN_URL case with an
explicit 'if (accept == ACCEPT_KNOWN_URL) return' and a new
BUG() guard in the ACCEPT_NONE case.
- Call accept_from_server_url() from filter_promisor_remote()
and relax its early return so that the function is entered when
`accept_urls` has entries even if `accept == ACCEPT_NONE`.
With this, many organizations may only need something like:
git config set --global \
promisor.acceptFromServerUrl "https://my-org.com/*"
to accept only their own remotes. And if they need to accept additional
remotes in some specific repos, they can also set:
git config set promisor.acceptFromServer knownUrl
and configure the additional remote manually only in the repos where
they are needed.
Let's then properly document `promisor.acceptFromServerUrl` in
"promisor.adoc" as an additive security allowlist for known remotes,
including the URL normalization behavior and the component-wise
matching, and let's mention it in "gitprotocol-v2.adoc".
Also let's clarify in the documentation how
`promisor.acceptFromServerUrl` interacts with
`promisor.acceptFromServer`:
- Precedence: when both options are set,
`promisor.acceptFromServerUrl` is consulted first. If a matching
pattern leads to acceptance, the remote is accepted regardless of
`promisor.acceptFromServer`. Otherwise the decision is left to
`promisor.acceptFromServer`.
- URL-mismatch guard: even when the advertised URL matches the
allowlist, an already-existing client-side remote whose configured
URL differs from the advertised one is not accepted through
`promisor.acceptFromServerUrl`. `promisor.acceptFromServer=all` and
`=knownName` keep their pre-existing, looser semantics.
The precedence paragraph is intentionally scoped here to known remotes
only (field updates). A following commit that introduces auto-creation
of unknown remotes will extend it to cover that case as well.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previous commits have introduced the `promisor.acceptFromServerUrl` config variable to allowlist some URLs advertised by a server through the "promisor-remote" protocol capability. However the new `promisor.acceptFromServerUrl` mechanism, like the old `promisor.acceptFromServer` mechanism, still requires a remote to already exist in the client's local configuration before it can be accepted. This places a significant manual burden on users to pre-configure these remotes, and creates friction for administrators who have to troubleshoot or manually provision these setups for their teams. To eliminate this burden, let's automatically create a new `[remote]` section in the client's config when a server advertises an unknown remote whose URL matches a `promisor.acceptFromServerUrl` glob pattern. Concretely, let's add four helpers: - sanitize_remote_name(): turn an arbitrary URL-derived string into a valid remote name by replacing non-alphanumeric characters, collapsing runs of '-', and prepending "promisor-auto-". - promisor_remote_name_from_url(): normalize the URL and extract host+port+path to build a human-readable base name, then pass it through sanitize_remote_name(). - configure_auto_promisor_remote(): write the remote.*.url, remote.*.promisor and remote.*.advertisedAs keys to the repo config. - handle_matching_allowed_url(): pick the final name (user-supplied alias or auto-generated), handle collisions by appending "-1", "-2", etc., then call configure_auto_promisor_remote(). Let's also add should_accept_new_remote_url() which reuses the url_matches_accept_list() helper introduced in a previous commit to find a matching pattern, then delegates to handle_matching_allowed_url() to create the remote. And then let's call should_accept_new_remote_url() from the '!item' (unknown remote) branch of should_accept_remote(), setting `reload_config` so that the newly-written config is picked up. Finally let's document all that by: - expanding the `promisor.acceptFromServerUrl` entry to describe auto-creation, the optional "name=" prefix syntax, the "promisor-auto-*" generation rules, and numeric-suffix collision handling, and by - adding a "remote.<name>.advertisedAs" entry to "remote.adoc". Also let's extend the precedence paragraph added by a previous commit to mention this new acceptance path: until now, the only way for `promisor.acceptFromServerUrl` to trigger acceptance was to allow field updates for a known remote. With this commit, it can also trigger auto-creation of a previously-unknown remote whose advertised URL matches the allowlist. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The entry for the `promisor.acceptFromServer` in "Documentation/config/promisor.adoc" has a number of issues: - it's not clear if new remotes and URLs can be created, - it looks like a big block of text, - it's not easy to see all the options, - it's not easy to see which option is the default one, - for "knownName", it says "advertised by the client" instead of "advertised by the server", - it doesn't refer to the new related `acceptFromServerUrl` option. Let's address all these issues by rewording large parts of it and using bullet points for the different options. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
…ta-islands * ds/path-walk-filters: path-walk: support `combine` filter path-walk: support `object:type` filter path-walk: support `tree:0` filter t6601: tag otherwise-unreachable trees pack-objects: support sparse:oid filter with path-walk path-walk: add pl_sparse_trees to control tree pruning path-walk: support blob size limit filter backfill: die on incompatible filter options path-walk: support blobless filter path-walk: always emit directly-requested objects t/perf: add pack-objects filter and path-walk benchmark pack-objects: pass --objects with --path-walk t5620: make test work with path-walk var
* ps/odb-source-loose: odb/source-loose: drop pointer to the "files" source odb/source-loose: stub out remaining callbacks odb/source-loose: wire up `write_object_stream()` callback object-file: refactor writing objects to use loose source odb/source-loose: wire up `write_object()` callback loose: refactor object map to operate on `struct odb_source_loose` odb/source-loose: wire up `freshen_object()` callback odb/source-loose: drop `odb_source_loose_has_object()` odb/source-loose: wire up `count_objects()` callback odb/source-loose: wire up `find_abbrev_len()` callback odb/source-loose: wire up `for_each_object()` callback odb/source-loose: wire up `read_object_stream()` callback odb/source-loose: wire up `read_object_info()` callback odb/source-loose: wire up `close()` callback odb/source-loose: wire up `reprepare()` callback odb/source-loose: start converting to a proper `struct odb_source` odb/source-loose: store pointer to "files" instead of generic source odb/source-loose: move loose source into "odb/" subsystem
…obal-state * ps/setup-centralize-odb-creation: setup: construct object database in `apply_repository_format()` repository: stop reading loose object map twice on repo init setup: stop initializing object database without repository setup: stop creating the object database in `setup_git_env()` repository: stop initializing the object database in `repo_set_gitdir()` setup: deduplicate logic to apply repository format setup: drop `setup_git_env()` t0001: plug test gaps for git-init(1) with GIT_OBJECT_DIRECTORY
When executing git-init(1) we need to figure out the final location of the worktree. This location can be configured in a couple of ways: via an environment variable, via the preexisting "core.worktree" config in case we're reinitializing, or implicitly when reinitializing a non-bare repository. When checking for the worktree location in "builtin/init-db.c" we populate any potentially-discovered value both by setting the global `git_work_tree_cfg` variable and via `set_git_work_tree()`, which ultimately ends up modifying `struct repository::worktree`. Modifying `git_work_tree_cfg` is unnecessary though: we configure the worktree in `create_default_files()`, and that function derives the worktree location via `repo_get_work_tree()`. Consequently, propagating the worktree via `set_git_work_tree()` is sufficient. Stop munging `git_work_tree_cfg` and make it file-local to "setup.c" and function-local to `cmd_init_db()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the preceding commit we have stopped modifying the global `git_work_tree_cfg` variable. With this change there's now some code paths where we end up setting the local `git_work_tree_cfg` variable, but without actually using the value for anything. Refactor the code a bit so that we only set the worktree configuration in case it's actually needed. Furthermore, reflow it a bit to make the code easier to follow. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The global `git_work_tree_cfg` variable used to be modified by both "setup.c" and by "builtin/init-db.c". We have refactored the latter user to not use that variable at all anymore in a preceding commit, which makes "setup.c" the only remaining user. Even for "setup.c" it is unnecessary though, as we only ever set it to the value we have stored in the discovered repository format. The consequence is that we only ever set it in case we already have it set to the same value in our discovered repository format, which makes it redundant. Refactor the code so that we instead use the worktree configuration as discovered via the repository format. Drop the global variable. Note that in `check_repository_format_gently()` we now have to free the candidate work tree variable. This change is required to retain previous semantics: before we essentially had an implicit `else` branch where we set `git_work_tree_cfg = NULL`, but we were able to elide that branch because we already knew that it would be `NULL` anyway. Now that we use the candidate work tree directly to populate the repository's work tree though we have to clear it to retain those semantics. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We're modifying `is_bare_repository_cfg` in "builtin/init.c" to indicate whether the newly created repository is supposed to be a bare repository or not. This is ultimately unnecessary though: when initializing the repository in `init_db()` we eventually set `is_bare_repository_cfg = !work_tree`, so all that matters is whether or not we have a working tree configured, and the working tree is set up in the non-bare in "builtin/init.c". Stop modifying the global variable in "builtin/init.c" in favor of a local variable. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `is_bare_repository_cfg` variable tracks two different pieces of
information:
- It tracks whether the user has invoked git with the "--bare" flag,
which makes us treat any discovered Git repository as if it was a
bare repository.
- Otherwise it tracks whether the discovered `the_repository` is bare.
This makes the flag extremely confusing and creates a bit of a challenge
when handling multiple repositories in the same process.
Split up the concerns of this variable into two pieces:
- `startup_info.force_bare_repository` tracks whether the user has
passed the "--bare" flag. This is used as a hint to treat newly set
up repositories as bare regardless of whether or not they have a
worktree.
- `struct repository::bare_cfg` tracks whether or not a repository is
considered bare. This takes into account both whether the user has
passed "--bare" and the discovered state of the repository itself.
Whether or not a repository is bare is now resolved when checking the
repository's format, and is then later applied to the repository itself
via `apply_repository_format()`.
This enables a subsequent change where we make `is_bare_repository()`
not depend on global state anymore.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor `is_bare_repository()` to take in a repository parameter so that we no longer depend on `the_repository`. Adjust callers accordingly. Furthermore, move the function outside of the declarations that are only available when `USE_THE_REPOSITORY_VARIABLE` is set, as it no longer depends on that variable. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adapt a couple of trivial callers of `is_bare_repository()` to instead use a repository available via the caller's context so that we can drop the `USE_THE_REPOSITORY_VARIABLE` macro. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
…values' Move the global 'protect_hfs' and 'protect_ntfs' configurations into the repository-specific 'repo_config_values' struct. This will help with the elimination of 'the_repository' To ensure code readability, the getter functions 'repo_protect_hfs()' and 'repo_protect_ntfs()' have been introduced. For now, associated functions access this configuration by explicitly falling back to 'the_repository', which needs to be addressed in the future. Note: In 't/helper/test-path-utils.c', there is a function 'protect_ntfs_hfs_benchmark()' where these two global variables are used as loop iterators. New local variables have been created to replace them. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Ayush Chandekar <ayu.chandekar@gmail.com> Mentored-by: Olamide Caleb Bello <belkid98@gmail.com> Signed-off-by: Tian Yuchen <cat@malon.dev> Signed-off-by: Junio C Hamano <gitster@pobox.com>
dabecb9 (for-each-ref: introduce a '--start-after' option, 2025-07-15) changed branch, remote-tracking branch, and tag enumeration from constructing an iterator with the namespace prefix to constructing an unscoped iterator and seeking to the prefix. Review of --start-after noted that the construction prefix and seek position represent different state and are easy to conflate [1]. It also noted that future branch or tag support would need to retain the namespace prefix while moving the cursor [2]. The files backend constructs its loose-ref iterator with cache priming enabled. cache_ref_iterator_begin() immediately applies the construction prefix through cache_ref_iterator_set_prefix(), reading loose refs beneath it before packed refs are opened. An empty prefix therefore reads every loose ref, and a later seek cannot undo that I/O. For the current single-kind filters, construct the iterator with the namespace prefix when start_after is not set. Leave the existing start_after path unchanged; no current command combines it with these filters, and future support must carry the prefix separately from the cursor. With 10,000 unrelated loose refs in the files backend, the p6300 tests improve as follows: before after branch 2.74 s 0.11 s branch --remotes 2.81 s 0.12 s tag 3.01 s 0.11 s [1] https://lore.kernel.org/r/aGZidwwlToWThkn8@pks.im/ [2] https://lore.kernel.org/r/xmqqikjq7s16.fsf@gitster.g/ Fixes: dabecb9 ("for-each-ref: introduce a '--start-after' option") Suggested-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
traverse_trees_wrapper() saves entries from a first pass through traverse_trees() and then replays them through the real callback (collect_merge_info_callback). However, the replay loop silently discards the callback return value. This is not a deferred error; it is an ignored error. Today the only originator of a negative return in this entire call graph is traverse_trees()'s "exceeded maximum allowed tree depth" check; everything else (collect_merge_info_callback, traverse_trees_wrapper, the inner traverse_trees recursion) only relays that. So in current Git, the visible effect of dropping the replay callback's return value is narrow but bad: a tree nested past core.maxTreeDepth has its -1 swallowed, the subtree below the limit is silently pruned, and the merge completes as if that were the correct result. A later patch in this series will teach collect_merge_info_callback() to return -1 on an additional path -- detecting duplicate entries in malformed trees -- which is similarly handled today by just ignoring the problem (resulting in mostly a "last one wins" rule, though the non-last entry can mutate various state flags). Capture the return value, stop the loop on negative returns, and propagate the error to the caller. The callback returns a positive mask value on success, so normalize non-negative returns to 0 for the caller. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
collect_merge_info() has set info.show_all_errors = 1 since d2bc199 (merge-ort: implement a very basic collect_merge_info(), 2020-12-13). This setting was copied from unpack-trees.c where it controls batching of error messages for porcelain display, but merge-ort has no such error-batching logic and never needed it. With show_all_errors set, traverse_trees() captures a negative callback return but continues processing remaining entries rather than stopping immediately. Removing the setting restores the default behavior where a negative return from collect_merge_info_callback() breaks out of the traversal loop right away, allowing a future commit to exit early when a corrupt tree is detected. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
clear_or_reinit_internal_opts() is responsible for cleaning up the various data structures in merge_options_internal. It already handles many renames-related structures (dirs_removed, dir_renames, relevant_sources, cached_pairs, deferred, etc.) but does not free renames->pairs[].queue. In the normal code path, resolve_and_process_renames() frees pairs[s].queue and reinitializes it with diff_queue_init() before clear_or_reinit_internal_opts() runs, so the omission is harmless. However, if collect_merge_info() encounters an error and returns early (before resolve_and_process_renames() is ever called), any diff pairs already queued by collect_rename_info()/add_pair() will have their backing array leaked. Fix this by freeing renames->pairs[].queue in the cleanup function. In the normal path the pointer is already NULL (from the earlier diff_queue_init() in resolve_and_process_renames()), so free(NULL) is a safe no-op. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Trees with duplicate entries are malformed; fsck reports "contains duplicate file entries" for them. merge-ort has from the beginning assumed that we would never hit such trees. It was written with the assumption that traverse_trees() calls collect_merge_info_callback() at most once per path. The "sanity checks" in that callback (added in d2bc199 (merge-ort: implement a very basic collect_merge_info(), 2020-12-13)) verify properties of each individual call but not that invariant. The strmap_put() in setup_path_info() silently overwrites the entry from any prior call for the same path, because it assumed there would be no other path. Unfortunately, supplemental data structures for various optimizations could still be tweaked before the extra paths were overwritten, and those data structures not matching expected state could trip various assertions. Change the return type of setup_path_info() from void to int to allow us to detect this case, and abort the merge with a clear error message when it occurs. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
verify_cache() checks that the index does not contain both "path" and
"path/file" before writing a tree. It does this by comparing only
adjacent entries, relying on the assumption that "path/file" would
immediately follow "path" in sorted order. Unfortunately, this
assumption does not always hold. For example:
docs <-- submodule entry
docs-internal/README.md <-- intervening entry
docs/requirements.txt <-- D/F conflict, NOT adjacent to "docs"
When this happens, verify_cache() silently misses the D/F conflict and
write-tree produces a corrupt tree object containing duplicate entries
(one for the submodule "docs" and one for the tree "docs").
I could not find any caller in current git that both allows the index to
get into this state and then tries to write it out without doing other
checks beyond the verify_cache() call in cache_tree_update(), but
verify_cache() is documented as a safety net for preventing corrupt
trees and should actually provide that guarantee. A downstream consumer
that relied solely on cache_tree_update()'s internal checking via
verify_cache() to prevent duplicate tree entries was bitten by the gap.
Add a test that constructs a corrupt index directly (bypassing the D/F
checks in add_index_entry) and verifies that write-tree now rejects it.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
eb54a33 (cat-file: skip expanding default format, 2022-03-15) added special handling for the default batch format. In the meantime it has fallen behind the code path for handling arbitrary formats. Bring it up to speed by using the new and more efficient strbuf_add_oid_hex() and strbuf_add_uint() instead of strbuf_addf(): Benchmark 1: ./git_main cat-file --batch-all-objects --batch-check='%(objectname) %(objecttype) %(objectsize)' Time (mean ± σ): 1.051 s ± 0.003 s [User: 1.027 s, System: 0.023 s] Range (min … max): 1.049 s … 1.058 s 10 runs Benchmark 2: ./git_main cat-file --batch-all-objects --batch-check='%(objectname)-%(objecttype)-%(objectsize)' Time (mean ± σ): 1.012 s ± 0.002 s [User: 0.988 s, System: 0.023 s] Range (min … max): 1.010 s … 1.018 s 10 runs Benchmark 3: ./git cat-file --batch-all-objects --batch-check='%(objectname) %(objecttype) %(objectsize)' Time (mean ± σ): 979.0 ms ± 1.1 ms [User: 954.1 ms, System: 23.2 ms] Range (min … max): 977.7 ms … 980.8 ms 10 runs Summary ./git cat-file --batch-all-objects --batch-check='%(objectname) %(objecttype) %(objectsize)' ran 1.03 ± 0.00 times faster than ./git_main cat-file --batch-all-objects --batch-check='%(objectname)-%(objecttype)-%(objectsize)' 1.07 ± 0.00 times faster than ./git_main cat-file --batch-all-objects --batch-check='%(objectname) %(objecttype) %(objectsize)' Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "MyFirstContribution" document recommends the use of deep threading of cover letters: every cover letter of subsequent iterations shall be linked to the cover letter of the preceding version. The result of this is that eventually, threads with many versions are getting nested so deep that it becomes hard to follow. Adapt the recommendation to instead propose shallow threading of cover letters: instead of linking the cover letter to the previous cover letter, the user is supposed to always link it to the first cover letter. This still makes it easy to follow the iterations, but has the benefit of nesting to a much shallower level. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The b4 tool originates from the Linux kernel community and is intended to help mailing-list based workflows. It automates a lot of the annoying bookkeeping tasks that contributors typically need to do: tracking the list of recipients, Message-IDs, range-diffs and the like. In addition to that, b4 also has many other subcommands that help the maintainer and reviewers. The Git project uses the same infrastructure as the kernel, so this tool is also a very good fit for us. Adapt "MyFirstContribution" to explicitly recommend its use. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the preceding commit we have extended our documentation to recommend
b4 for sending patch series to the mailing list. Introduce configuration
so that it knows to honor preferences of the Git project by default. For
now, this configuration does two things:
- It configures "send-same-thread = shallow", which tells b4 to always
send subsequent versions of the same patch series as a reply to the
cover letter of the first version.
- It configures "prep-cover-template", which tells b4 to use a custom
template for the cover letter. The most important change compared to
the default template is that our custom template also includes a
range-diff.
There's potentially more things that we may want to configure going
forward, like for example auto-configuration of folks to Cc on certain
patches. But these two tweaks feel like a good place to start.
Note that these values only serve as defaults, and users may want to
tweak those defaults based on their own preference. Luckily, users can
do that without having to touch `.b4-config` at all, as b4 allows them
to override values via Git configuration:
```
$ git config set b4.prep-cover-template /does/not/exist
$ b4 send --dry-run
ERROR: prep-cover-template says to use x, but it does not exist
```
So this gives users an easy way to override our defaults without having
to touch ".b4-config", which would dirty the tree.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When initializing the reftable stack the caller may optionally pass some
write options. These write options mix up two different concerns though:
- Of course, they allow the caller to configure how new reftables are
being written.
- But they also allow the caller to configure the stack itself, like
its hash ID and the `on_reload` callback.
This is somewhat awkward, as it doesn't easily give the caller the
flexibility to for example write multiple reftables with different
options. Furthermore, this requires us to eagerly parse relevant
configuration when initializing the reftable backend.
Refactor the code by splitting out those options that configure the
stack itself. Creating a new stack will thus only require this limited
set of options, whereas the caller is expected to pass write options to
all functions that end up writing tables.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Same as with the "files" backend, the "reftable" backend also has a chicken-and-egg problem with "onbranch" conditions. Fix this issue the same as we did with the "files" backend by lazy-loading configuration. Now that both the "files" and the "reftable" backend handle this properly, add a generic test to t1400 that verifies that the user can configure "core.logAllRefUpdates" via an "onbranch" condition. This is mostly a nonsensical thing to do in the first place, but it serves as a good sanity check. Note that we had to move `should_write_log()` around so that it can access the new `reftable_be_write_options()` function. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the preceding commits we have fixed recursion when creating the reference backends due to a chicken-and-egg situation with "onbranch" conditions. Unfortunately, this issue has existed for a while, and we didn't really have a good mechanism to detect this recursion. Improve the status quo by detecting the recursion when creating the main reference store. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Several tests in 't3420-rebase-autostash.sh' start various rebase processes that are expected to fail because of merge conflicts. The tests [1] checking that 'git rebase --quit' and autostash work together as expected after such a failure then run '! grep ...' to ensure that the dirty contents of the file is gone. However, due to the test repo's history and the choice of upstream branch that file shouldn't exist in the conflicted state at all, and thus it shouldn't exist after the subsequent 'git rebase --quit' either. Consequently, this 'grep' doesn't fail as expected, i.e. because it can't find the dirty content, but instead it fails, because it can't open the file. Thighten this check by using 'test_path_is_missing' instead, thereby avoiding unexpected errors from 'grep' as well. Previously 2745817 (t3420-rebase-autostash: don't try to grep non-existing files, 2018-08-22) fixed a couple of similar issues; this one was added later in 9b2df3e (rebase: save autostash entry into stash reflog on --quit, 2020-04-28). [1] This patch modifies only a single test, but that test is run several times with different strategies ('--apply', '--merge', and '--interactive'), hence the plural "tests". Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Advice shown by "git status" when the local branch is behind or has diverged from its push branch has been updated to suggest "git pull <remote> <branch>". * hn/status-pull-advice-qualified: remote: qualify "git pull" advice for non-upstream compareBranches
The handling of promisor-remote protocol capability has been updated to allow the other side to add to the list of promisor remotes via the 'promisor.acceptFromServerURL' configuration variable. * cc/promisor-auto-config-url-more: doc: promisor: improve acceptFromServer entry promisor-remote: auto-configure unknown remotes promisor-remote: trust known remotes matching acceptFromServerUrl promisor-remote: introduce promisor.acceptFromServerUrl promisor-remote: add 'local_name' to 'struct promisor_info' urlmatch: add url_normalize_pattern() helper urlmatch: change 'allow_globs' arg to bool t5710: simplify 'mkdir X' followed by 'git -C X init'
The refactoring of 'setup.c' has been continued to drop remaining global state (`git_work_tree_cfg`, `is_bare_repository_cfg`), updating `is_bare_repository()` to no longer implicitly rely on `the_repository`. * ps/setup-drop-global-state: treewide: drop USE_THE_REPOSITORY_VARIABLE environment: stop using `the_repository` in `is_bare_repository()` environment: split up concerns of `is_bare_repository_cfg` builtin/init: stop modifying `is_bare_repository_cfg` setup: remove global `git_work_tree_cfg` variable builtin/init: simplify logic to configure worktree builtin/init: stop modifying global `git_work_tree_cfg` variable
Project-specific configuration for b4 has been introduced, and the documentation has been updated to recommend using it as a streamlined method for submitting patches. * ps/doc-recommend-b4: b4: introduce configuration for the Git project MyFirstContribution: recommend the use of b4 MyFirstContribution: recommend shallow threading of cover letters
The default format path of git cat-file --batch has been optimized to use strbuf_add_oid_hex() and strbuf_add_uint() instead of strbuf_addf(), yielding a noticeable speedup. * rs/cat-file-default-format-optim: cat-file: speed up default format
A regression in the error diagnosis code for invalid .git files has been fixed, avoiding a potential NULL-pointer crash when reporting that a .git file does not point to a valid repository. * jk/setup-gitfile-diag-fix: read_gitfile(): simplify NOT_A_REPO error message
The 'ort' merge backend has been hardened against corrupt trees by ensuring it aborts under appropriate error conditions. * en/ort-harden-against-corrupt-trees: cache-tree: fix verify_cache() to catch non-adjacent D/F conflicts merge-ort: abort merge when trees have duplicate entries merge-ort: free diff pairs queue in clear_or_reinit_internal_opts() merge-ort: drop unnecessary show_all_errors from collect_merge_info() merge-ort: propagate callback errors from traverse_trees_wrapper()
Commands that list branches and tags (like git branch and git tag) have been optimized to pass the namespace prefix when initializing their ref iterator, avoiding a loose-ref scaling regression in repositories with many unrelated loose references. * td/ref-filter-restore-prefix-iteration: ref-filter: restore prefix-scoped iteration
The packed object source has been refactored into a proper struct odb_source. * ps/odb-source-packed: odb/source-packed: drop pointer to "files" parent source midx: refactor interfaces to work on "packed" source odb/source-packed: stub out remaining functions odb/source-packed: wire up `freshen_object()` callback odb/source-packed: wire up `find_abbrev_len()` callback odb/source-packed: wire up `count_objects()` callback odb/source-packed: wire up `for_each_object()` callback odb/source-packed: wire up `read_object_stream()` callback odb/source-packed: wire up `read_object_info()` callback packfile: use higher-level interface to implement `has_object_pack()` odb/source-packed: wire up `reprepare()` callback odb/source-packed: wire up `close()` callback odb/source-packed: start converting to a proper `struct odb_source` odb/source-packed: store pointer to "files" instead of generic source packfile: move packed source into "odb/" subsystem packfile: split out packfile list logic packfile: rename `struct packfile_store` to `odb_source_packed`
The global configuration variables protect_hfs and protect_ntfs have been migrated into struct repo_config_values to tie them to per-repository configuration state. * ty/move-protect-hfs-ntfs: environment: use 'repo->initialized' for repo_protect_hfs() and repo_protect_ntfs() environment: move 'protect_hfs' and 'protect_ntfs' into 'repo_config_values'
Support for hashing loose or packed objects larger than 4GB on Windows and other LLP64 platforms has been improved by converting object header buffers and data-handling functions from 'unsigned long' to 'size_t'. * po/hash-object-size-t: hash-object: add a >4GB/LLP64 test case using filtered input hash-object: add another >4GB/LLP64 test case hash-object --stdin: verify that it works with >4GB/LLP64 hash algorithms: use size_t for section lengths object-file.c: use size_t for header lengths hash-object: demonstrate a >4GB/LLP64 problem
The `fetch.followRemoteHEAD` configuration variable has been added to provide a default for the per-remote `remote.<name>.followRemoteHEAD` setting. * mh/fetch-follow-remote-head-config: fetch: fixup a misaligned comment fetch: add configuration variable fetch.followRemoteHEAD fetch: refactor do_fetch handling of followRemoteHEAD fetch: return 0 on known git_fetch_config fetch: rename function report_set_head t5510: cleanup remote in followRemoteHEAD dangling ref test doc: explain fetchRemoteHEADWarn advice fetch: fixup set_head advice for warn-if-not-branch
The trailer sections in SubmittingPatches have been updated to encourage use of standard trailers. * kh/submittingpatches-trailers: SubmittingPatches: note that trailer order matters SubmittingPatches: be consistent with trailer markup SubmittingPatches: document Based-on-patch-by trailer SubmittingPatches: discourage common Linux trailers SubmittingPatches: encourage trailer use for substantial help
The documentation in SubmittingPatches has been updated to clarify how patch contributors should respond to design and viability critiques, and how the resolution of such critiques should be recorded in the final commit messages. * jc/submittingpatches-design-critiques: SubmittingPatches: address design critiques
The pack-objects command has been updated to support reachability bitmaps and delta-islands concurrently with the `--path-walk` option, allowing faster packaging by falling back to path-walk when bitmaps cannot fully satisfy the request. * tb/pack-path-walk-bitmap-delta-islands: pack-objects: support `--delta-islands` with `--path-walk` pack-objects: extract `record_tree_depth()` helper pack-objects: support reachability bitmaps with `--path-walk` t/perf: drop p5311's lookup-table permutation
The display of the rebase todo list in "git status" has been improved to correctly abbreviate object IDs for more commands and avoid misinterpreting refs as object IDs. * pw/status-rebase-todo: status: improve rebase todo list parsing sequencer: factor out parsing of todo commands
"git log --follow" has been updated to better handle non-linear history, in which the path being tracked gets renamed differently in multiple history lines. * mv/log-follow-mergy: log: improve --follow following renames for non-linear history
The "git repo info" command has been taught new keys to output both absolute and relative paths for "gitdir" and "commondir", supported by a new path-formatting helper extracted from "git rev-parse". * jk/repo-info-path-keys: repo: add path.gitdir with absolute and relative suffix formatting repo: add path.commondir with absolute and relative suffix formatting path: extract format_path() and use in rev-parse
Documentation on community contribution guidelines has been updated to encourage replying to review comments before rerolling, and to advise a default limit of at most one reroll per day to give reviewers across different time zones enough time to participate. * wy/doc-clarify-review-replies: doc: advise batching patch rerolls doc: encourage review replies before rerolling
Reference backend configuration has been updated to load lazily to avoid recursive calls during repository initialization when 'onbranch' configuration conditions are evaluated. This has also fixed a memory leak and allowed the unused `chdir_notify_reparent()` machinery to be dropped. * ps/refs-onbranch-fixes: refs: protect against chicken-and-egg recursion refs/reftable: lazy-load configuration to fix chicken-and-egg reftable: split up write options refs/files: lazy-load configuration to fix chicken-and-egg refs: move parsing of "core.logAllRefUpdates" back into ref stores repository: free main reference database chdir-notify: drop unused `chdir_notify_reparent()` refs: unregister reference stores from "chdir_notify" setup: don't apply "GIT_REFERENCE_BACKEND" without a repository setup: stop applying repository format twice setup: inline `check_and_apply_repository_format()`
The connectivity check has been refactored to search for promisor objects in a generic way using the object database interface, rather than iterating packfiles directly. This allows connectivity checks to work properly in repositories that do not use packfiles. * ps/connected-generic-promisor-checks: connected: search promisor objects generically connected: split out promisor-based connectivity check odb/source-packed: support flags when iterating an object prefix odb/source-packed: extract logic to skip certain packs
A test checking interactions between git rebase --quit and autostash in t3420-rebase-autostash.sh has been corrected to use test_path_is_missing instead of ! grep on a file that shouldn't exist in the conflicted state. * sg/t3420-do-not-grep-in-missing-file: t3420-rebase-autostash: don't try to grep non-existing files
This time, do not forget to update GIT-VERSION-GEN to say 2.55.GIT Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )