-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow multiple diff opt args #188
Closed
svenwest
wants to merge
267
commits into
stacked-git:master
from
svenwest:allow-multiple-diff-opt-args
Closed
allow multiple diff opt args #188
svenwest
wants to merge
267
commits into
stacked-git:master
from
svenwest:allow-multiple-diff-opt-args
+20,839
−278
Conversation
This file contains 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
Use STG_RUST=debug STG_RUST=release to execute tests with debug or release builds, respectively.
The test suite does not set user.name and user.email, instead relying on GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, etc. environment variables. CheckedSignature is reworked to no longer rely on Repository::signature(), which only knows how to derive a signature from the user.name and user.email configuration. The env vars are consulted first, and only when absent are user.name and user.email consulted.
This improves compatibility with the test suite, but may need to be revisited.
The user-provided StGit revision is parsed Add -b/--branch option for id. This is a new feature compared to the Python version. Another difference vs Python version: the provided revspec is not always peeled to a commit object. This specifically affects the output of annotated tags where, e.g. `stg id v1.3` shows the id of the commit the tag points to where as `git rev-parse v1.3` shows the id of the tag itself.
When no patches are applied, the head is the top, by definition.
- Use patchdesc.tmpl when user does not provide a message. - Check for conflicts in index before starting transaction.
The cmd module now takes responsibility for collecting all the StGit commands. The new StGitCommand struct defines a common function call interface for commands. Each command module defines a get_command() function that returns its StGitCommand instance. In main(), the clap::App can now be setup more generically, without main() having to have knowledge of each individual command.
Aliases in the Rust version differ from aliases in the Python version and now behave like Git aliases. - Aliases for external commands must be prefixed with '!'. E.g.: git config stgit.alias.long-status '!git status --long' would enable: stg long-status - Aliases for StGit commands are not prefixed. E.g.: git config stgit.alias.list 'series --short' would enable: stg list Other details: - Aliases that attempt to override any builtin command are ignored - Added builtin aliases: add, mv, resolved, rm, status. - Builtin aliases may be overridden or removed (by making empty). - Recursive aliases are detected Resolves stacked-git#97
cc, git2, libc, serde_json, syn
Forward fmt() to PatchName's inner String to allow format parameters to be applied correctly. This specifically affected `stg series` where the patch name sometimes needs to be displayed with a minimum width.
Minimize the overhead of running StGit subcommands by avoiding two relatively heavy lifts unless needed: 1. Do not lookup aliases unless the user provides an unknown subcommand. 2. Do not construct clap::App instances for all subcommands; only construct the App for the user-specified subcommand unless the user provides an unknown subcommand. The net of this is that in the happy path, where the user provides a known stgit subcommand on the command line, main() will get right to work on that subcommand without a bunch of unneeded overhead.
Use GENERAL_ERROR (1) and COMMAND_ERROR (2) constants to better match the python implementation's return code strategy. A remaining and intentional difference is that any error detected during command line parsing is a GENERAL_ERROR whereas the Python implementation would return COMMAND_ERROR for many classes of command line problem, for example for option conflicts.
Also: - make the -b/--branch argument available to multiple subcommands. - make --color available too
These dead functions will be used later...
- Proper option conflicts with -a/--all - Implement --showbranch - Correct help for --showbranch - Implement --missing - Implement --short - Update tests
The user may now specify the patch range(s) to be shown via patch range arguments. This implementation differs from the Python version in that the patch ranges specified must be (a) in-order and (b) contiguous. The Python version did not impose either of those constraints, which allowed for some hilariously wrong/misleading outputs. New tests are implemented.
The base is the first patch's *parent*.
This is done for compatibility with the Python version.
The new `stg status` alias behaves slightly differently w.r.t. the Python version, but more aligned with `git status` in that submodule paths are shown relative to the worktree root.
Instead of using a single PatchDesription structure to represent both the outgoing/editable patch description and the incoming/user-edited description, now use two different structures. The specific motivation is to be able to distinguish the cases from the user-edited patch description: - "Patch:" header present with patch name value - "Patch:" header present with empty patch name value - "Patch:" header absent When the "Patch:" header is absent, the patch name now reverts to the original patch name, whereas when the "Patch:" header is present with an empty value the patch name is generated from the message. The driving assumption is that the "Patch:" header being entirely absent indicates that the user is just writing a message and isn't trying to rename or otherwise alter the patch name. On the other hand, when "Patch: " is found with an empty value, the user explicitly deleted the pre-filled patch name. This is interpreted as the user desiring for the patch name to be regenerated from the message. If the user had wanted to retain the original patch name, they would have simply left the "Patch:" header and value unaltered.
Compat: - For interactive rebase, the "squash" and "fixup" instructions may no longer be used with the first patch in the instructions list. The stated semantics of both squash and fixup is that they squash the labeled patch with the preceding patch, which is not possible/valid when there is no preceding patch.
This method tests whether a commit's tree is the same as its parent's tree, which indicates no changes.
The repository state was being inspected instead of checking for conflicts in the index.
The dedicated error was no longer necessary since this error now only happens in the check_repository_state() method.
There is only one place this error happens, so don't need an explicit error variant.
The FoldConflicts error variant was being used in several commands to indicated that the StGit command caused conflicts; the new name better reflects that.
This is consistent with clap's error message and the Python implementation, where most error messages start with uppercase letters.
The string "None" may show up as a value for "prev" in stack.json if the stack was upgraded by the Python implementation of StGit. This value is now treated the same as `null` instead of attempting to parse it as an object id.
If `stg series -s` was run with no applied patches and the number of unapplied patches was less than stgit.shortnr, a panic would occur due to indexing out-of-bounds of a patches vector.
These build-time features allow several dependencies that only relate to `stg import` to be optional. - import-compressed: bzip2, flate2, tar - import-url: curl Also remove "url" as a dependency, since it was unused.
This is the last command that relied on the Python implementation of StGit, but it is not being implemented in Rust, at least for the time being. The rationale is that it is not clear that `stg mail` provides sufficient value versus running `git send-email`. Consider, for example: $ stg mail p0..p4 The alternative using git would be: $ git send-email $(stg id p0)..$(stg id p4) Or: $ git send-email refs/patches/main/p0..refs/patches/main/p4 N.B. `git send-email` provides a very wide selection of options, both on the command line and in the config, to fine-tune how emails are sent. `stg mail` only offered a subset of those capabilities. Perhaps the most obvious feature that `stg mail` had that `git send-email` does not [quite] have is customizable patch templates. This feature, however, may be more trouble than its worth since it allows patch emails to deviate from git email standards. Note that git allows the branch description to be used as the cover letter (i.e. with --cover-from-description), so that seems like a viable replacement for `stg mail`'s cover letter template.
The merge capability of `git read-tree -u -m` is needed more broadly than previously thought. So when performing checkouts at stack transaction execute time, use `git read-tree` instead of git2::Repository.checkout_tree() for all cases except the trivial case when discarding any outstanding work tree changes. Also correct the error mapping so that any read-tree error is reported to the user properly.
The Python implementation's parse_patches() function has the semantic where open-ended patch ranges (i.e. "[patch]..") may be bounded to the last applied patch when the beginning patch of the open-ended range is an applied patch. That semantic is now implemented in the Rust version. Also enhance patch range parsing to identify misspelled patch names and report relevant similar patch names in user-facing error messages.
Various commands are updated to use the same internal and user-facing conventions for patch ranges. Patch range arguments have a user-facing value name of "patch", which means usage strings show either "[patch]..." or "<patch>...", depending on whether the argument is optional. This user-facing naming deemphasizes the range capability, instead emphasizing the simpler case of specifying individual patch name arguments. Improved documentation is needed to allow users to discover the range capability. Also update usage strings for various commands.
This function parses a single patch name argument, verifying that it is known to the stack and is in an allowed list (applied, unapplied, hidden). It also performs string similarity matching on unknown patches and provides user-facing error messages with the similar patch names. This isolates use of the strsim crate to the patchrange module.
The Zsh completions script is updated such that StGit subcommands and aliases are now derived from the `stg -h` output from the Rust implementation. The stg executable is now fast enough that caching the parsed command list is no longer necessary. And since the description of aliases contain the complete alias expansion, the completion script can also derive what it needs to know about aliases from the `stg -h` output without having to consult `git config`. This works for both StGit's built-in aliases as well as user-defined aliases, which means the completions script no longer needs baked-in knowledge of the built-in aliases.
When searching for -b/--branch options in the command line, false positives would occur due to not checking that the index of the -b/--branch option was valid.
The STG_TEST_PROFILE indicates which cargo build profile should be tested; currently either "dev" or "release" (where "debug" may be used as an alias to "dev"). The Python implementation may still be tested by setting STG_TEST_PYTHON to a non-empty value.
When running `stg edit --set-tree`, disable implicit edit such that the editor is not invoked.
Since only the mode bits are needed (for testing whether a hook is executable), the more general unix MetadataExt can be used instead of the linux-specific MetadataExt. This matches the cfg test and allows StGit to build on non-Linux UNIX platforms (e.g. MacOS).
Lints are performed via `cargo fmt` and `cargo clippy`. Both the API docs and the legacy man pages are built. Both the unit test suite (`cargo test`) and the system test suite are run. The build matrix currently covers release & dev build profiles and stable & nightly Rust toolchains. Adding operating systems is anticipated. Added scheduled build so that StGit can be tested against new nightly and stable Rust toolchain releases even when StGit code isn't changing. Do not [currently] need a deep fetch-depth when cloning the repository because the version is not derived from `git describe` output.
On platforms using case-insensitive filesystems, having two patch names in the same stack that only differ by case will cause patch reference collisions. E.g. `p0` and `P0` would use the same reference file: `.git/refs/patches/<branch>/p0`. To avoid this hazard, StGit is modified to disallow case-insensitive collisions of patch names within a stack. When new patch names are generated with PatchName::uniquify(), a case-insensitive comparision is performed to ensure the uniqified name differs by more than just case from all other patch names in the stack. And the new Stack::collides() method is used instead of Stack::has_patch() to test whether user-provided patch names collide with any existing patch names.
A few of the tests rely on sed behavior specific to GNU sed, where MacOS ships with BSD sed. So gnu-sed is installed for the MacOS test.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
stg pull
on a branch without upstream set is causing an Exception #83): fix stg pull when no upstream is configuredstg refresh
errors out when index contains added files and path limiting is given #85): fix refresh crashes when index contains added files and path limitingnew
with patchdescr.template (Existance of patchdescr.tmpl causes TypeError #87)stg log
with patches from subdirstg new
without--verbose
.stg edit -d
stg edit
with binary diffsstg rebase
new-base-idstg branch --list
stg branch --list
stg import --message-id
optionstg repair
with amended first patchstg sink --nopush
capabilitystg new
to workstg id
stg new
to pass more testsstg top
stg prev
stg series
stg series
stg id
stg next
stg status
aliasstg push
stg pop
stg goto
stg sink
stg float
stg delete
stg rename
stg hide
stg id
stg show
stg new
stg refresh
stg spill
stg new
stg edit
stg edit
stg clean
stg diff
stg commit
stg patches
stg edit -d
stg files
stg uncommit
stg export
stg import
stg reset
stg undo
andstg redo
stg fold
stg log
stg branch
stg log
outputstg log
stg repair
stg pick
stg sync
stg clone
commandstg squash
stg pull
stg rebase
stg series -s
edge casestg mail
git read-tree
for all transaction checkoutsstg edit --set-tree
to not run the editor