Follows up on https://github.com/jj-vcs/jj/pull/5698 and
https://github.com/jj-vcs/jj/pull/6236.
The behavior of `--named` in corner cases differs. This wasn't detected
in #5698 because of a bug in the test that was fixed in #6236. This
commit better illustrates the more important case where the behavior is
the same, and the less important case where it differs.
Follow-up to b1bb5e1
This creates a `.github/scripts/count-cargo-lock-packages` script to
count packages with our methodology that one can run outside CI.
I also renamed the check so that it's clearer what it does.
After some discussion on Discord yesterday, Emily floated this idea to
have a check that fails if `Cargo.lock` has too many dependencies, where
"too many" means "more than a random number I made up and sounds good."
This implements that, as a non-required check, and to do so it invokes
the power of an extremely evil and annoying Dragon. We could also ask
this Dragon to do other things too I suppose (pending future contract
negotiations).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
In docs/templates.md, the Commit type and Operation type looked like:
`method() -> ReturnType`
rather than everything else, which looks like:
`.method() -> ReturnType`
This commit changes the Commit and Operation types to look more like the
rest of the documentation.
Fix GHSA-794x-2rpg-rfgr.
`gix::Repository::work_dir` was renamed to `workdir` (though strangely
not the `gix::ThreadSafeRepository` version), and `lossy_config`
is now off by default in all configurations.
These merge tools didn't work properly on conflicted trees with more
than two sides since they didn't simplify the conflict before resolving.
The new implementation is more similar to how external merge tools are
executed, which should give a more consistent behavior.
Previously, this was calling `git_repository_open()`,
which is equivalent to `git_repository_open_ext()` with
`flags = GIT_REPOSITORY_OPEN_NO_SEARCH` and `ceiling_dirs =
NULL`. This changes `ceiling_dirs` to an empty string, and adds
`GIT_REPOSITORY_OPEN_FROM_ENV` to `flags` when we’re in test code.
`GIT_REPOSITORY_OPEN_FROM_ENV` is used to respect the Git configuration
path environment variables, which is what we want for the test
hermeticity code. It works like this:
* `config_path_system` will use `$GIT_CONFIG_SYSTEM` because `use_env`
will be set.
* `config_path_global` will use `$GIT_CONFIG_GLOBAL` because `use_env`
will be set.
* `git_config__find_xdg` and `git_config__find_programdata` will find
impure system paths and load them even when `$GIT_CONFIG_GLOBAL` is
set, contrary to Git behaviour, so we need to set `$XDG_CONFIG_HOME`
and `$PROGAMDATA`.
It has a few other effects, which I will exhaustively enumerate to
show that they are benign:
* It respects `$GIT_WORK_TREE` and `$GIT_COMMON_DIR`. These would
already break our tests, I think, so we’re assuming they’re
not set. (Possibly we should set them explicitly.)
* When opening a repository, it will:
* Set the starting path for the search to `$GIT_DIR` if it’s
`NULL`, but we do set it, so no change.
* Initialize `ceiling_dirs` to `$GIT_CEILING_DIRECTORIES` if it’s
`NULL`, but we do set it, so no change.
* Respect `$GIT_DISCOVERY_ACROSS_FILESYSTEM` and set the
`GIT_REPOSITORY_OPEN_CROSS_FS` flag appropriately. However,
this is only checked on subsequent iterations of the loop in
`find_repo_traverse`, and we set `GIT_REPOSITORY_OPEN_NO_SEARCH`
which causes it to never enter a second iteration.
* Use `ceiling_dirs` in `find_ceiling_dir_offset`, but the result is
ignored when `GIT_REPOSITORY_OPEN_NO_SEARCH` is set, so changing
from `NULL` to the empty string doesn’t affect behaviour. (It
also would always return the same result for either value, anyway.)
- Now computes the latest tag automatically in the first suggested command.
- Now excludes dependabot.
I used the command to generate the list of contributors in the v0.28.0 release commit.
If a commit needs fixing but its descendant does not, we currently
skip rewriting the descendant, which means it will instead be rebased
when the transactions finished. That usually results in
conflicts. This adds a test case for that case.
With this template, a 'git format-patch' compatible
email message can be generated using something like:
jj show --git --template git_format_patch_email_headers <rev>