[pull] master from git:master - #238
Merged
Merged
Conversation
The memoized contains traversal used by git tag assumes that commit ancestry is acyclic. Replacement refs can violate that assumption, causing it to keep pushing an already active commit until memory is exhausted. Mark commits while they are active and die if the traversal encounters an active commit. Other failures in this walk already die through parse_commit_or_die(); using a second reachability walk would only add a separate policy for malformed history. Suggested-by: Kristofer Karlsson <krka@spotify.com> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git branch and git for-each-ref run a separate reachability walk for each ref considered by --contains and --no-contains. Refs with shared history therefore traverse the same commits repeatedly. git tag instead uses a depth-first walk that caches results across refs. That walk can perform poorly without generation numbers: a negative check may walk to the root instead of stopping at a nearby divergence. Generation numbers let it stop below the oldest target. Use the memoized walk for all ref-filter callers when generation numbers are available. Keep git tag on its existing path without generations. Caching still helps when many tags share deep history: ffc4b80 (tag: speed up --contains calculation, 2011-06-11) reduced git tag --contains HEAD~200 in linux-2.6 from 15.417 to 5.329 seconds. The new shared-history perf test improves from 0.72 to 0.03 seconds. In a repository with 62,174 remote-tracking refs, running: git branch -r --contains c78ae85f3ce7e improves from 104.365 seconds to 468 milliseconds. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without generation numbers, repo_is_descendant_of() can return -1 when it cannot read commit ancestry. commit_contains() exposes that result through a Boolean interface, so ref-filter treats it as true. This can include a ref for --contains or exclude it for --no-contains without failing the command. Die when repo_is_descendant_of() reports an error. The memoized walk already dies when it cannot parse a commit, so callers of the non-memoized path no longer turn a failed walk into a match. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
…tory * ps/refs-writing-subcommands: builtin/refs: add "rename" subcommand builtin/refs: add "create" subcommand builtin/refs: add "update" subcommand builtin/refs: add "delete" subcommand builtin/refs: drop `the_repository`
check_graph is a function shared in the test files t4215 and t6016 used to format the output graph, but instead of being in a file called by both test, the function code is repeated in each file. Move check_graph to lib-log-graph.sh file which both tests already import graph functions from, renaming it to lib_test_check_graph. This function is needed for the following commit which includes graph tests in a new file and requires check_graph. Mentored-by: Karthik Nayak <karthik.188@gmail.com> Mentored-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_revision() gets its commits from two sources depending on the mode: 1. Normally it gets the commits from get_revision_internal(). 2. --max-count-oldest which was introduced at bb4ce23 (revision.c: implement --max-count-oldest, 2026-05-19) gets the commits by popping from a saved list at revs->commits marking SHOWN and CHILD_SHOWN on each popped commit. Extract the choice logic into a helper, next_commit_to_show(), which returns the next commit regardless of the source it comes from. This has no change in behavior. The helper is needed in a subsequent commit that pre-fetches two commits into a buffer for lookahead purposes and needs to pre-fetch from the same source. The --reverse branch keeps its own pop loop. Using the helper for --reverse would additionally set SHOWN and CHILD_SHOWN which is not desired and a behavior change. Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a subsequent commit the graph renderer needs to know if the next commit is a visual root or if it is the last commit to be shown. This requires peeking 2 commits ahead. Commits are pre-fetched in get_revision() through next_commit_to_show() where they are also marked as SHOWN, regardless the source they come from. Update graph_is_interesting() so it considers commits inside the lookahead buffer as interesting as well. Helped-by: Kristofer Karlsson <krka@spotify.com> Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rendering a graph, if the history contains multiple "visual roots",
actual roots or commits that look like roots (i.e. have their parents
filtered out) can end up being vertically adjacent to unrelated commits,
falsely appearing to be related.
A fix for this issue was already attempted [1] a while ago.
This happens because the commits fill the space from left to right and
when a visual root ends, its column becomes free for the following
commit even if they are not related. Once this happens the unrelated
commit is rendered below the visual root. Because there is no special
character or way to identify when a visual root is rendered making the
graph confusing.
By indenting the visual roots when there are still commits to show the
vertical adjacency can be avoided.
Add is_visual_root flag to git_graph making it visible in all graph states,
give graph_update() a new function, graph_is_visual_root() to know if the
current commit is a visual root and set is_visual_root.
The different handled cases are:
- If a visual root has children: similar to GRAPH_PRE_COMMIT state when
octopus merges need space, an edge row needs to be printed to connect
the child with the indented visual root. A new state GRAPH_PRE_ROOT is
needed to connect the child with the visual root:
* child of the visual root
\ GRAPH_PRE_ROOT
* visual root indented
- If a visual root is child-less we can skip GRAPH_PRE_ROOT state and
render the indented commit directly.
* visual root indented
* unrelated commit
- If two or more visual roots are adjacent: by having a lookahead to the
next commit that will be rendered, if the next commit is also a visual
root and we are on a visual root, meaning two visual root adjacent in
the history, the top one can omit the indent, making the one below to
indent only once, if there are more adjacent visual commits, the
indentation will increase for each adjacent one, cascading.
* visual root
* visual root
* visual root
* last commit
Even if the last commit is a root, because there is nothing that will be
rendered below we can omit the indentation on purpose.
[1]: https://lore.kernel.org/git/xmqqwnwajbuj.fsf@gitster.c.googlers.com/
Helped-by: Kristofer Karlsson <krka@spotify.com>
Mentored-by: Karthik Nayak <karthik.188@gmail.com>
Mentored-by: Chandra Pratap <chandrapratap3519@gmail.com>
Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently the visual root commits in a graph cascade indefinitely until
a commit which is not a visual root or the last commit appears.
On filters like --author where one author might contribute mostly on
single patches this can become a visual issue.
Make the cascading wrap after 4 columns.
There are two possible cases of the wrap:
1. No ambiguity:
* A
* B
* C
* D
* E
* F
2. Ambiguous conflict:
If F happens to not be a visual root and E gets wrapped back to the
initial column then E and F would be vertically adjacent. The solution
is to forcefully indent E one level:
* A
* B
* C
* D
* E
* F
* F
The magic number 4 comes as the minimum number of columns to wrap where
the output shows clearly the commits are unrelated and doesn't cause too
much "pyramid" effects
Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the repo_config_get_string() call out of graph_init() and into graph_read_config(). This simplifies graph_init() and provides a function for future graph-related config opt. This commit is a preparatory commit for a subsequent one. Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users may prefer to not have graph indentation. Add "log.graphIndent" config variable to graph_read_config() to read the default preference. By default is graph indentation is true. Add --graph-indent and --no-graph-indent options to overwrite the default preference. Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that the merge backend is the default, we have lost coverage for "git rebase --apply" copying notes. Fix this by replacing "-m" with "--apply" as the previous test which uses the default backend now checks the merge backend. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If an external merge strategy cannot merge (for example because it would overwrite an untracked file) it exits with a non-zero exit code other than 1. This should be treated differently from a merge with conflicts, which is signaled by an exit code of 1, because, as the merge failed, we need to reschedule the last pick. The caller expects us to return -1 in this case. Also reschedule without trying to merge if the commit message cannot be written as that prevents us from successfully picking the commit. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If "git commit" fails to run then run_git_commit() returns -1 which causes the current command to be rescheduled. This is incorrect as we have successfully picked the commit and have written all the state files we need to successfully commit when the user continues. Fix this by converting -1 to 1 which matches what do_merge() does. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If error_with_patch(..., res, ...) succeeds then it returns "res", if it fails then it returns -1. This means that or-ing the return value with "res" is pointless as the result is the same as the return value. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit e032abd (rebase: fix rewritten list for failed pick, 2023-09-06) introduced an early return when res == -1, so if we enter this conditional block then res is positive. After the last couple of commits the only possible positive value is 1. That means we can simplify the code by removing the conditional call to intend_to_amend() and have error_failed_squash() request that it is called in error_with_patch() instead. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
item->commit holds the commit to be picked and so it must be non-NULL otherwise pick_one_commit() would not know which commit to pick. It is also unconditionally dereferenced in do_pick_commit() which is called at the top of this function. Therefore the check to see if it is non-NULL is superfluous. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unless we're rebasing, all we do in pick_one_commit() is call do_pick_commit() and return its result. Simplify the code by returning early if we're not rebasing so that we don't have to repeatedly call is_rebase_i() in the rest of the function. Note that there are a couple of conditions that do not call is_rebase_i() but they check for either an "edit" or a "fixup" command, both of which imply we're rebasing. The only block that does not return early is the one guarded by "!res". Move the return into that block to make it clear that after recording the commit as rewritten, all we do is return from the function. As the conditional blocks are all mutually exclusive (either the conditions are mutually exclusive, or an earlier conditional block that would match a later one contains a "return" statement) chain them together with "else if" to make that clear. While we could remove "res" from the conditions below "if (!res)" they are left alone because, when we start using an enum in the next commit, it makes it clear that these clauses are handling cases where there are conflicts. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rather than using an integer where -1 is an error, 0 is success and 1 indicates there were conflicts, use an enum. This is clearer and lets us add a separate return value for commits that are dropped because they become empty in the next commit. Note we continue to use "return error(...)" to return errors and take advantage of C's lax typing of enums Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a commit gets dropped because its changes are already upstream then we should not record it as rewritten. As well as confusing any post-rewrite hooks, it means we end up copying the notes from the dropped commit to the commit that was picked immediately before the one that was dropped. While we do not want to record the dropped commit as rewritten, if it is the final commit in a chain of fixups then we need to flush the list of rewritten commits. The behavior of an "edit" command where the commit is dropped is changed so that "rebase --continue" will not amend the previous pick. However, as the code comment notes it will still be erroneously recorded as rewritten when the rebase continues. That will need to be addressed separately along with not recording skipped commits as rewritten. The initialization of "drop_commit" is moved to ensure it is initialized when rewording a fast-forwarded commit. Reported-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Tested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since d7d850e (CodingGuidelines: mention C99 features we can't use, 2022-10-10), our CodingGuidelines document has explicitly forbidden the use of '%z' and '%zu' printf() format specifiers, even though C99 does support them. However, a new instance crept in via 82c36fa (submodule: hash the submodule name for the gitdir path, 2026-01-12). We could claim that this is an unintentional weather balloon that nobody has complained about for the past six months since Git 2.54, proving that it is now safe to use these format specifiers. But (1) it is probably too early to make that claim, as distributions often stick to a stale version for several releases, and (2) it is unlikely that a failure in this code path would manifest as a major user-visible breakage that would trigger a failure report to percolate down to us. Instead, let's stick to the established workaround recommended by our CodingGuidelines, which is to cast the value to (uintmax_t) and format it with PRIuMAX, at least for now. Even if we eventually perform a bulk update using a Coccinelle script to transition to %z and %zu in the future, adding one more instance to the pile that will need such a conversion is hardly a tragedy. Signed-off-by: Junio C Hamano <gitster@pobox.com>
The push specs are kept in a strvec, whose array is NULL-terminated. Pass only that to the protocol handlers, which avoids dealing with item counts and their conversions from size_t to int, slightly simplifying the code. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When locking the "packed-refs" file we allow the user to configure a timeout for how long we try taking the lock. This is configurable via "core.packedRefsTimeout", which we parse in `packed_refs_lock()`. The parsed value is stored in function-static variables though, which of course has the effect that we'll only ever use the timeout configured in the first packed reference store that we see. Consequently, if we ever were to handle stores from different repositories, then we'd use the same configuration for both stores even if they diverge. This is of course a somewhat theoretical concern -- we don't typically handle multiple packed stores, and even if we did it's very unlikely that the user has configured different timeout values for each of them. But still, this is a code smell, and an unnecessary one, too. Fix the issue by moving the value into `struct packed_ref_store` so that it can be parsed per store. This removes the last callsite that still used `the_repository`, so drop the `USE_THE_REPOSITORY_VARIABLE` define. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have a bunch of users of `the_repository` in the "files" backend, all of which are trivial to convert to instead use the backend's own repo. Do so. There is one more dependency on global state though via `ignore_case`, and thus we can't trivially remove `USE_THE_REPOSITORY_VARIABLE`. But this is the only use of global state, and we want to ensure that we don't unwittingly reintroduce a dependency on `the_repository` going forward. Add an extern declaration for `ignore_case` so that it becomes accessible even without `USE_THE_REPOSITORY_VARIABLE` and drop the define itself. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In "worktree.c" we have lots of users of `the_repository` that already have a repository available to them. Convert all of them to use that repository instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have a bunch of file-local functions that use `the_repository`. Adapt them so that the repository is instead passed as a parameter so that we can get rid of this dependency. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor remaining public functions that still depend on `the_repository` to instead receive a repository as parameter. This allows us to get rid of `USE_THE_REPOSITORY_VARIABLE`. Adapt callers accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are still a couple of callsites that use `the_repository`. Convert these to instead use a repository injected by the caller. This allows us to remove `USE_THE_REPOSITORY_VARIABLE`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorganize the refspec header a bit so that structures and their related functions are grouped closer together. While at it, fix a couple of style violations. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When parsing a refspec item we need to know about the hash algorithm used by the repository so that we can decide whether or not a given string is an exact object ID. We use `the_hash_algo` for this, which makes the code implicitly depend on `the_repository`. Refactor `refspec_item_init_fetch()`, `refspec_item_init_push()` and `valid_fetch_refspec()` so that callers have to pass in the hash algorithm explicitly and adapt callers accordingly. For now, all of the callers simply pass `the_hash_algo`, so there is no change in behaviour. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only remaining user of `the_hash_algo` in "refspec.c" is `refspec_append()`, which needs to know the hash algorithm so that it can parse the appended refspec item. In contrast to the functions adapted in the preceding commit, this function always operates on a `struct refspec`. As that structure is expected to only ever contain refspecs that all use the same hash function it doesn't make sense though to adapt each caller. Instead, adapt the structure itself so that it gets initialized with a hash function and use that hash function to parse new refspec items. Adapt callers accordingly. This removes the final dependency on the global repository variable in "refspec.c", so we can drop `USE_THE_REPOSITORY_VARIABLE`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When copying a file we need to potentially adapt permissions of the new file based on whether or not "core.shared" is enabled. Parsing this configuration makes us implicitly depend on `the_repository`. Refactor the code to instead require the caller to pass in a repository so that we can remove `USE_THE_REPOSITORY_VARIABLE`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt_status_collect_untracked() copies entries from dir.entries and dir.ignored into string_lists using string_list_insert(). At first glance this seems quadratic, because inserting into the sorted list may shift the backing array, incurring O(n) work for each insert. In practice, though, the entries in the dir struct are already sorted, so we should not have to shift the array and only pay the O(log n) lookup cost for each insertion. But this is subtle and depends on the behavior of fill_directory(). Collect the entries with string_list_append() instead, then sort and deduplicate each list once with string_list_sort_u(). This preserves the sorted, duplicate-free result while making the collection strategy explicit. Signed-off-by: Sahitya Chandra <sahityajb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our C-based clone helper requires that the context be initialized, but we neglect to do that in our Clone implementation for CryptoHasher. This does not matter when using our default block SHA-256 implementation, but it does cause a crash when using OpenSSL as the backend. Fix this by properly initializing the context before cloning into it. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we allocate a context but then abandon it, we never discard it,
which means that the underlying crypto library context may leak. This
doesn't happen with our default block code, but it may with OpenSSL.
Note that we do call git_hash_free, which frees the memory we called
from git_hash_alloc, but doesn't discard the underlying context itself.
This can be seen with the following command when compiling with OpenSSL
and running with nightly Rust:
RUSTFLAGS='-Z sanitizer=leak' cargo test
Discard the context in our context handler. Note that it is fine to do
so even after finalizing the context, so our final functions which take
self instead of &mut self will not mishandle memory.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git log --graph' has been modified to visually distinguish parentless 'root' commits (and commits that become roots due to history simplification) by indenting them, preventing them from appearing falsely related to unrelated commits rendered immediately above them. * ps/shift-root-in-graph: graph: add --[no-]graph-indent and log.graphIndent graph: move config reading into graph_read_config() graph: wrap cascading commits after 4 columns graph: indent visual root in graph graph: add a 2 commit buffer for lookahead revision: add next_commit_to_show() lib-log-graph: move check_graph function
An accidental use of the '%zu' format specifier in 'git submodule--helper' has been corrected to use 'PRIuMAX' and cast the value to 'uintmax_t' to avoid portability issues. * jc/submodule-helper-avoid-zu: submodule--helper: avoid use of %zu for now
The ref subsystem and the worktree API have been refactored to pass a repository pointer down the call chain, allowing them to drop references to the global 'the_repository' variable. As part of this, the handling of the 'core.packedRefsTimeout' configuration has been moved into the per-repository ref store structure. * ps/refs-wo-the-repository: refs: remove remaining uses of `the_repository` worktree: pass repository to public functions worktree: pass repository to file-local functions worktree: refactor code to use available repositories refs/files: drop `USE_THE_REPOSITORY_VARIABLE` refs/packed: de-globalize handling of "core.packedRefsTimeout"
'git branch --contains' and 'git for-each-ref --contains' have been optimized to use the memoized commit traversal previously used only by 'git tag --contains', significantly speeding up connectivity checks across many candidate refs with shared history. * td/ref-filter-memoize-contains: commit-reach: die on contains walk errors ref-filter: memoize --contains with generations commit-reach: reject cycles in contains walk
The passing of push destination specifications in the 'remote-curl' helper has been simplified by removing the explicit 'count' parameter and relying on the NULL-termination of the array. * rs/remote-curl-simplify-push-specs: remote-curl: simplify passing of push specs
The dependency on the global 'the_repository' variable in the 'refspec.c' API has been removed by passing the hash algorithm explicitly to refspec-parsing functions and storing it in 'struct refspec'. * ps/refspec-wo-the-repository: refspec: stop depending on `the_repository` refspec: let callers pass in hash algorithm when parsing items refspec: group related structures and functions
The enumeration of untracked and ignored files in 'git status' has been optimized by avoiding quadratic complexity when inserting into string lists, reducing the construction cost from O(n^2) to O(n log n). * sc/wt-status-avoid-quadratic-insertion: wt-status: avoid repeated insertion for untracked paths
The copy_file() and copy_file_with_time() functions have been refactored to take a repository parameter, allowing the removal of the implicit dependency on the global 'the_repository' variable in 'copy.c'. * ps/copy-wo-the-repository: copy: drop dependency on `the_repository`
The rebase post-rewrite notes-copying logic has been corrected. When a commit is dropped during rebase (e.g., because its changes are already upstream), it is no longer recorded as rewritten, preventing its notes from being copied to an unrelated commit. * pw/rebase-drop-notes-with-commit: sequencer: do not record dropped commits as rewritten sequencer: use an enum to represent result of picking a commit sequencer: simplify pick_one_commit() sequencer: remove unnecessary condition in pick_one_commit() sequencer: simplify handling of fixup with conflicts sequencer: remove unnecessary "or" in pick_one_commit() sequencer: never reschedule on failed commit sequencer: be more careful with external merge t3400: restore coverage for note copying with apply backend
A few memory problems in the Rust interface to C hash functions have been corrected. The 'Clone' implementation of 'CryptoHasher' now properly initializes the context before cloning, and its 'Drop' implementation now discards the context to prevent leaks. * bc/rust-hash-cleanups: rust: discard hash context when finished hash: initialize context before cloning
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.
8 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 : )