Improve rebase empty commit advice #484
Closed
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
I tried out 'git format-patch --base' with a set of commits that modifies more than one file. It turns out that the way this command is implemented it actually uses the unstable version of patch-id instead of the stable version that's documented. When I tried to modify the existing test to use 'git patch-id --stable' vs. 'git patch-id --unstable' I found that it didn't matter, the test still passed. Let's expand on the test here so it is a little more complicated and then use that to show that the patch-id generation is actually unstable vs. stable. Update the documentation as well. Cc: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We weren't flushing the context each time we processed a hunk in the patch-id generation code in diff.c, but we were doing that when we generated "stable" patch-ids with the 'patch-id' tool. Let's port that similar logic over from patch-id.c into diff.c so we can get the same hash when we're generating patch-ids for 'format-patch --base=' types of command invocations. Cc: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Internally, git-format-patch uses the `handle_revision_opt` parser. The parser handles the `--no-notes` option to negate an earlier `--notes` option, but it isn't documented. Document this option so that users are aware of it. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both remove_branch_state() and drop_save() delete almost the same set of files about the current merge state. The only difference is MERGE_RR but it should also be cleaned up after a successful merge, which is what drop_save() is for. Make a new function that deletes all merge-related state files and use it instead of drop_save(). This function will also be used in the next patch that introduces --quit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "prefix" variable passed by git.c into the builtin cmd_read_tree()
and cmd_write_tree() functions is named "unused_prefix". But we do in
fact pass it to parse_options(), which may use the prefix to adjust any
filename options. Let's get rid of this confusing name.
However, we can't just call it "prefix". The reason these variables were
renamed in the first place is that they shadowed local variables named
"prefix", because these commands both take a "--prefix" option.
So let's rename the parameters, but try to reduce further confusion:
1. In both cases we'll call them "cmd_prefix" to mark that they're
part of the cmd_* interface.
2. In cmd_write_tree(), we'll rename the local prefix variable to
"tree_prefix" to make it more clear that we're talking about the
prefix to be used for the tree we're writing.
3. In cmd_read_tree(), the "prefix" local has since migrated into
"struct unpack_trees_options". We'll leave that alone, as the
context within the struct makes its meaning clear (we actually
_could_ just call the parameter "prefix" now, but that invites
confusion in the other direction).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a builtin uses RUN_SETUP to request that git.c enter the repository directory, we'll get passed in a "prefix" variable with the path to the original directory. It's important to pass this to parse_options(), since we may use it to fix up relative OPT_FILENAME() options. Some builtins don't bother; let's make sure we do so consistently. There may not be any particular bugs fixed here; OPT_FILENAME is actually pretty rare, and none of these commands use it directly. However, this does future-proof us against somebody adding an option that uses it and creating a subtle bug that only shows up when you're in a subdirectory of the repository. In some cases, like hash-object and upload-pack, we don't specify RUN_SETUP, so we know the prefix will always be empty. It's still worth passing the variable along to keep the idiom consistent across all builtins (and of course it protects us if they ever _did_ switch to using RUN_SETUP). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We stopped using the "prefix" parameter of relocate_single_git_dir_into_superproject() and its callers in 202275b (submodule.c: get_super_prefix_or_empty, 2017-03-14), where we switched to using the environment global directly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ever since the inception of this function in e6baf4a (clone: clone from a repository with relative alternates, 2011-08-22), the "dest" parameter has been unused. Instead, we use add_to_alternates_file(), which relies on git_pathdup() to find the right file. That in turn works because we will have initialized and entered the destination repo by this point. It's a bit subtle, but this is how it has always worked. And if our assumptions change, the test in t5601 from e6baf4a should let us know. In the meantime, let's drop this unused and confusing parameter from copy_alternates(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The load_cache_entries_threaded() function takes a src_offset parameter that it doesn't use. This has been there since its inception in 77ff112 (read-cache: load cache entries on worker threads, 2018-10-10). Digging on the mailing list, that parameter was part of an earlier iteration of the series[1], but became unnecessary when the code switched to using the IEOT extension. [1] https://public-inbox.org/git/20180906210227.54368-5-benpeart@microsoft.com/ Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The v2_fix_up_changed() function doesn't actually need to see the wt_status struct. It's possible that could change in the future, but this is a static-local function with one caller. It would be easy to read-add it back then. Let's drop the unused parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The mktree_line() function does not actually look at the "len" parameter it is passed, and assumes the buffer it receives is NUL-terminated. Since the caller always passes a strbuf, this will be true. Let's drop the useless parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When this function was extracted in 0041bf6 (name-rev: refactor logic to see if a new candidate is a better name, 2017-03-29), it ended up getting more arguments than it needs. It's possible we may later use these values to evaluate the name, but since it's a static function with a single caller, it will be easy to add them back then. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When collecting the list of objects to pack in get_object_list(), we pass our rev_info struct around to some functions that don't need it. This is due to 03a9683 (Simplify is_kept_pack(), 2009-02-28), where the kept-pack handling was moved out of the revision machinery. Let's drop these unused parameters. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We pass in the list of proposed ref updates to prepare_shallow_update(), but that function doesn't actually need it (and never has since its inception in 0a1bc12). Only its caller, update_shallow_info(), needs to look at the command list. Let's drop the unused parameter to reduce confusion. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function already takes a "key" parameter which uniquely identifies the config key that we need to remove. There's no need for it to look at the "remote" parameter at all. Let's drop it in the name of simplicity. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our finish_commit() function used to be passed directly to the revision machinery as a callback. But after 9899372 (rev-list: fix --verify-objects --quiet becoming --objects, 2012-02-28), it is used only as a helper in show_commit(). It doesn't use its void "data" parameter, and we no longer have to conform to the callback interface. Let's drop it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This ref_name parameter was never used since the inception of show_independent() in 1f8af48 (show-branch: --list and --independent, 2005-09-09). Let's drop it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The buf/len parameters of run_gpg_verify() have never been used since the function was added in d07b00b (verify-commit: scriptable commit signature verification, 2014-06-23). Instead, check_commit_signature() accesses the commit struct directly. Worse, we read the whole object just to check its type and do not attach it to the "struct commit". Meaning we end up loading the object from disk twice for no good reason. And to further confuse matters, our type check is comes from what we read from disk, but we later assume that lookup_commit() will return non-NULL. This might not be true if some other object previously referenced the same oid as a non-commit (though this may be impossible to trigger in practice since we don't generally parse any other objects in this command). Instead, let's do our type check by loading the object via parse_object(). That will attach the buffer to the struct so it can be used later by check_commit_signature(). And it ensures that lookup_commit() will return something sane. And then we can just drop the unused "buf" and "len" parameters entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is in preparation for a later change where we'll read the config first before parsing command-line options. As the move detection will show no lines (except one line of comment) is changed here, just moved around. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "to" and "cc" variables are named @initial_{to,cc}, let's rename
this one to match them.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the git-send-email command-line argument parsing and config reading code to parse those two in the right order. I.e. first we set our hardcoded defaults, then we read our config, and finally we read the command-line, with later sets overriding earlier sets. This fixes a bug introduced in e67a228 ("send-email: automatically determine transfer-encoding", 2018-07-08). That change broke the reading of sendmail.transferencoding because it wasn't careful to update the code to parse them in the previous "defaults -> getopt -> config" order. But as we can see from the history for this file doing it this way was never what we actually wanted, it's just something we grew organically as of 5483c71 ("git-send-email: make options easier to configure.", 2007-06-27) and have been dealing with the fallout since, e.g. in 463b0ea ("send-email: Fix %config_path_settings handling", 2011-10-14). As can be seen in this change the only place where we actually want to do something clever is with the to/cc/bcc variables, where setting them on the command-line (or using --no-{to,cc,bcc}) should clear out values we grab from the config. All the rest are things where the command-line should simply override the config values, and by reading the config first the config code doesn't need all this "let's not set it, if it was on the command-line" special-casing, as [1] shows we'd otherwise need to care about the difference between whether something was a default or present in config to fix the bug in e67a228. 1. https://public-inbox.org/git/20190508105607.178244-2-gitster@pobox.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
As discussed in [1] there's a regression in the "pu" branch now because a new test implicitly assumed that a previous test guarded by a prerequisite had been run. Add a "GIT_TEST_FAIL_PREREQS" special test setup where we'll skip (nearly) all tests guarded by prerequisites, allowing us to easily emulate those platform where we don't run these tests. As noted in the documentation I'm adding I'm whitelisting the SYMLINKS prerequisite for now. A lot of tests started failing if we lied about not supporting symlinks. It's also unlikely that we'll have a failing test due to a hard dependency on symlinks without that being the obvious cause, so for now it's not worth the effort to make it work. 1. https://public-inbox.org/git/nycvar.QRO.7.76.6.1905131531000.44@tvgsbejvaqbjf.bet/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test used an author with non-ascii characters in the name, but no special commit message. It then grep'ed for those non-ascii characters, but those are guaranteed to exist regardless of the reencoding process since the reencoding only affects the commit message, not the author or committer names. As such, the test would work even if the re-encoding process simply stripped the commit message entirely. Modify the test to actually check that the reencoding into UTF-8 worked. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since git supports commit messages with an encoding other than UTF-8, allow fast-import to import such commits. This may be useful for folks who do not want to reencode commit messages from an external system, and may also be useful to achieve reversible history rewrites (e.g. sha1sum <-> sha256sum transitions or subtree work) with git repositories that have used specialized encodings in their commit history. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When fast-export encounters a commit with an 'encoding' header, it tries to reencode in UTF-8 and then drops the encoding header. However, if it fails to reencode in UTF-8 because e.g. one of the characters in the commit message was invalid in the old encoding, then we need to retain the original encoding or otherwise we lose information needed to understand all the other (valid) characters in the original commit message. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The find_encoding() function returned the encoding used by a commit message, returning a default of git_commit_encoding (usually UTF-8). Although the current code does not differentiate between a commit which explicitly requested UTF-8 and one where we just assume UTF-8 because no encoding is set, it will become important when we try to preserve the encoding header. Since is_encoding_utf8() returns true when passed NULL, we can just return NULL from find_encoding() instead of returning git_commit_encoding. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
…sted Automatic re-encoding of commit messages (and dropping of the encoding header) hurts attempts to do reversible history rewrites (e.g. sha1sum <-> sha256sum transitions, some subtree rewrites), and seems inconsistent with the general principle followed elsewhere in fast-export of requiring explicit user requests to modify the output (e.g. --signed-tags=strip, --tag-of-filtered-object=rewrite). Add a --reencode flag that the user can use to specify, and like other fast-export flags, default it to 'abort'. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 2185362 (built-in rebase: call `git am` directly, 2019-01-18), the built-in rebase already uses the built-in `git am` directly. Now that d03ebd4 (rebase: remove the rebase.useBuiltin setting, 2019-03-18) even removed the scripted rebase, there is no longer any user of `git-rebase--am.sh`, so let's just remove it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
One test case's title mentioned the then-current implementation detail that the `--am` backend was implemented in `git-rebase--am.sh`. This is no longer the case, so let's update the title to reflect the current reality. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This went away in 0609b74 (rebase -i: combine rebase--interactive.c with rebase.c, 2019-04-17). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The data collected by fsmonitor was not properly written back to the on-disk index file, breaking t7519 tests occasionally, which has been corrected. * js/fsmonitor-unflake: mark_fsmonitor_valid(): mark the index as changed if needed fill_stat_cache_info(): prepare for an fsmonitor fix
"git p4" update. * sw/git-p4-unshelve-branched-files: git-p4: allow unshelving of branched files
Update to Unicode 12.1 width table. * bb/unicode-12.1-reiwa: unicode: update the width tables to Unicode 12.1
A new tutorial targetting specifically aspiring git-core developers. * es/first-contrib-tutorial: doc: add some nit fixes to MyFirstContribution documentation: add anchors to MyFirstContribution documentation: add tutorial for first contribution
"git help git" was hard to discover (well, at least for some people). * po/git-help-on-git-itself: Doc: git.txt: remove backticks from link and add git-scm.com/docs git.c: show usage for accessing the git(1) help page
The command line to invoke a "git cat-file" command from inside "git p4" was not properly quoted to protect a caret and running a broken command on Windows, which has been corrected. * mm/p4-unshelve-windows-fix: p4 unshelve: fix "Not a valid object name HEAD0" on Windows
"git request-pull" learned to warn when the ref we ask them to pull from in the local repository and in the published repository are different. * pb/request-pull-verify-remote-ref: request-pull: warn if the remote object is not the same as the local one request-pull: quote regex metacharacters in local ref
When creating a partial clone, the object filtering criteria is recorded for the origin of the clone, but this incorrectly used a hardcoded name "origin" to name that remote; it has been corrected to honor the "--origin <name>" option. * xl/record-partial-clone-origin: clone: respect user supplied origin name when setting up partial clone
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the case of merge conflicts, while performing a revert, we are currently advised to use `git cherry-pick --<sequencer-options>`. Introduce a separate advice message for `git revert`. Also change the signature of `create_seq_dir` to handle which advice to display selectively. Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We are on a path to teach cherry-pick/revert how to skip commits. To achieve this, we could really make use of existing functions. reset_for_rollback is one such function, but the name does not intuitively suggest to use it to reset a merge, which it was born to perform, see 539047c ("revert: introduce --abort to cancel a failed cherry-pick", 2011-11-23). Change the name to reset_merge to make it more intuitive. Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Avoid using magic numbers for array size and index under `reset_merge` function. Use `argv_array` instead. This will make code shorter and easier to extend. Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git am or rebase have a --skip flag to skip the current commit if the user wishes to do so. During a cherry-pick or revert a user could likewise skip a commit, but needs to use 'git reset' (or in the case of conflicts 'git reset --merge'), followed by 'git (cherry-pick | revert) --continue' to skip the commit. This is more annoying and sometimes confusing on the users' part. Add a `--skip` option to make skipping commits easier for the user and to make the commands more consistent. In the next commit, we will change the advice messages hence finishing the process of teaching revert and cherry-pick "how to skip commits". Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous commit introduced a --skip flag for cherry-pick and revert. Update the advice messages, to tell users about this less cumbersome way of skipping commits. Also add tests to ensure everything is working fine. Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a number of places where we compare two revisions with
test $(git rev-parse rev1) = $(git rev-parse rev2)
when these fail there's no indication what has gone wrong and you need
to be running with `-x` to see where the test has failed. Lets use
test_cmp_rev instead.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
In dcb500d (cherry-pick/revert: advise using --skip, 2019-07-02), `git commit` learned to suggest to run `git cherry-pick --skip` when trying to cherry-pick an empty patch, but that was never tested for. Here is a test that verifies that a message is given to the user that contains the correct invocation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We disallow partial commits and amending when CHERRY_PICK_HEAD exists. Add a couple of tests to check the error message printed in each case before we refactor the code responsible for this. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
`git commit` relies on the presence of CHERRY_PICK_HEAD to show the correct error message in the case of an empty pick. This fixes a regression introduced by the conversion from shell to C. In the shell version everything was a cherry-pick as far as the sequencer code was concerned so it always wrote CHERRY_PICK_HEAD. The conversion to C forgot to update the code that creates CHERRY_PICK_HEAD. We do not want to create CHERRY_PICK_HEAD for fixup and squash commands as that would prevent `git commit --amend` from running. Note that the error message shown by `git commit` for an empty pick during a rebase is currently wrong as it talks about running `git cherry-pick --skip` rather than `git rebase --skip`. This will be fixed in a future commit which is why the tests are in t3403-rebase-skip.sh. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Add FROM_CHERRY_PICK_MULTI for a sequence of cherry-picks rather than using a separate variable. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Working out which command wants to create a commit requires detailed knowledge of the sequencer internals and that knowledge is going to increase in subsequent commits. With that in mind lets encapsulate that knowledge in sequencer.c rather than spreading it into builtin/commit.c. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
In dcb500d (cherry-pick/revert: advise using --skip, 2019-07-02), `git commit` learned to suggest to run `git cherry-pick --skip` when trying to cherry-pick an empty patch. However, it was overlooked that there are more conditions than just a `git cherry-pick` when this advice is printed (which originally suggested the neutral `git reset`): the same can happen during a rebase. Let's suggest the correct command, even during a rebase. While at it, we adjust more places in `builtin/commit.c` that incorrectly assumed that the presence of a `CHERRY_PICK_HEAD` meant that surely this must be a `cherry-pick` in progress. Note: we take pains to handle the situation when a user runs a `git cherry-pick` _during_ a rebase. This is quite valid (e.g. in an `exec` line in an interactive rebase). On the other hand, it is not possible to run a rebase during a cherry-pick, meaning: if both `rebase-merge/` and `sequencer/` exist or CHERRY_PICK_HEAD and REBASE_HEAD point to the same commit , we still want to advise to use `git cherry-pick --skip`. Original-patch-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Add a specific message to advise the user what to do when a fixup or squash command would create an empty commit. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> --- I'm slightly nervous of moving the call to determine_whence() to finalized_deferred_config() I think it is ok but need to do a more through audit of the code to be sure.
Since the inception of CHERRY_PICK_HEAD in d7e5c0c ("Introduce CHERRY_PICK_HEAD", 2011-02-19) 'rebase -i' has removed it when there are conflicts. The rationale for this was that the rebase wanted to handle the conflicts itself. However sometimes (e.g. after an edit command) the user wants to commit the conflict resolution before making some other changes or running some tests. Without CHERRY_PICK_HEAD the authorship information is lost when the user makes the commit. Fix this by leaving CHERRY_PICK_HEAD when we're not amending. Note that this changes the output of `git status`. The advice to run `git reset` is not appropriate for rebase as we do not allow partial commits. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> --- NB I haven't checked how this affects the shell prompt in contrib yet, I suspect it may need changing to cope the presence of CHERRY_PICK_HEAD during a rebase.
|
@dscho how do I tell gitgitgadet what base to use when sending out patches? - I've added Based-on: but I'm not sure what that is used for |
@phillipwood First hit the Edit button:
Then use the drop-down menu to choose a different branch, and click Save:
The base commit must be a branch tip (or the merge base between your branch and the base branch), other base commits are not supported by GitGitGadget. |
@dscho thanks. Oh dear, this is based on a merge of two branches :-(. ra/cherry-pick-revert-skip is in master but if I rebase onto just pw/rebase-empty-commit-advice then I have to add the tests from ra/cherry-pick-revert-skip into this series. I think I'll just use |
I would have simply used |
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.
This is a reroll of js/advise-rebase-skip[1]. I've added some more commits to improve the test coverage and handle edit & reword as well as pick commands. I've also changed the advice printed by an empty cherry-pick performed during a rebase to be the same whether it is part of a sequence of cherry-picks or just a single pick.
There are a couple of RFC patches at the end that change the advice for fixups that empty HEAD and change the handling of CHERRY_PICK_HEAD so if a user commits a conflict resolution the authorship is preserved.
These patches are based on a merge of ra/cherry-pick-revert-skip and pw/sequencer-compare-with-right-parent-to-check-empty-commits
[1] https://lore.kernel.org/git/pull.417.git.1571787022.gitgitgadget@gmail.com
Cc: Johannes Schindelin johannes.schindelin@gmx.de
Based-on: d5e6c1d