git/rebase-interactive.c, branch v2.35.2

rebase: remove a no-longer-used function

2021-09-08T04:45:33Z

With the `--preserve-merges` option going away, we no longer need this function. Helped-by: Alban Gruin Signed-off-by: Johannes Schindelin Reviewed-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

rebase -i: clarify and fix 'fixup -c' rebase-todo help

2021-02-10T21:58:19Z

When `-c` says "edit the commit message" it's not clear what will be edited. The original's commit message or the replacement's message or a combination of the two. Word it such that it states more precisely what exactly will be edited. While at it, also drop the jarring period and capitalization, neither of which is otherwise present in the message. Mentored-by: Christian Couder Mentored-by: Phillip Wood Helped-by: Eric Sunshine Signed-off-by: Charvi Mendiratta Signed-off-by: Junio C Hamano

rebase -i: add fixup [-C | -c] command

2021-01-29T23:21:56Z

Add options to `fixup` command to fixup both the commit contents and message. `fixup -C` command is used to replace the original commit message and `fixup -c`, additionally allows to edit the commit message. Original-patch-by: Phillip Wood Mentored-by: Christian Couder Mentored-by: Phillip Wood Signed-off-by: Charvi Mendiratta Signed-off-by: Junio C Hamano

Merge branch 'rt/format-zero-length-fix'

2020-03-09T18:21:21Z

Recently we inadvertently added a few instances of using 0-width format string to functions that we mark as printf-like without any developers noticing. The root cause was that the compiler warning that is triggered by this is almost always useless and we disabled the warning in our developer builds, but not for general public. The new instances have been corrected, and the warning has been resurrected in the developer builds. * rt/format-zero-length-fix: config.mak.dev: re-enable -Wformat-zero-length rebase-interactive.c: silence format-zero-length warnings

Merge branch 'en/rebase-backend'

2020-03-02T23:07:19Z

"git rebase" has learned to use the merge backend (i.e. the machinery that drives "rebase -i") by default, while allowing "--apply" option to use the "apply" backend (e.g. the moral equivalent of "format-patch piped to am"). The rebase.backend configuration variable can be set to customize. * en/rebase-backend: rebase: rename the two primary rebase backends rebase: change the default backend from "am" to "merge" rebase: make the backend configurable via config setting rebase tests: repeat some tests using the merge backend instead of am rebase tests: mark tests specific to the am-backend with --am rebase: drop '-i' from the reflog for interactive-based rebases git-prompt: change the prompt for interactive-based rebases rebase: add an --am option rebase: move incompatibility checks between backend options a bit earlier git-rebase.txt: add more details about behavioral differences of backends rebase: allow more types of rebases to fast-forward t3432: make these tests work with either am or merge backends rebase: fix handling of restrict_revision rebase: make sure to pass along the quiet flag to the sequencer rebase, sequencer: remove the broken GIT_QUIET handling t3406: simplify an already simple test rebase (interactive-backend): fix handling of commits that become empty rebase (interactive-backend): make --keep-empty the default t3404: directly test the behavior of interest git-rebase.txt: update description of --allow-empty-message

rebase-interactive.c: silence format-zero-length warnings

2020-02-28T16:39:09Z

Fixes the following warnings: rebase-interactive.c: In function ‘edit_todo_list’: rebase-interactive.c:137:38: warning: zero-length gnu_printf format string [-Wformat-zero-length] write_file(rebase_path_dropped(), ""); rebase-interactive.c:144:37: warning: zero-length gnu_printf format string [-Wformat-zero-length] write_file(rebase_path_dropped(), ""); Signed-off-by: Ralf Thielow Signed-off-by: Junio C Hamano

rebase (interactive-backend): make --keep-empty the default

2020-02-16T23:40:42Z

Different rebase backends have different treatment for commits which start empty (i.e. have no changes relative to their parent), and the --keep-empty option was added at some point to allow adjusting behavior. The handling of commits which start empty is actually quite similar to commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default, 2018-06-27), which pointed out that the behavior for various backends is often more happenstance than design. The specific change made in that commit is actually quite relevant as well and much of the logic there directly applies here. It makes a lot of sense in 'git commit' to error out on the creation of empty commits, unless an override flag is provided. However, once someone determines that there is a rare case that merits using the manual override to create such a commit, it is somewhere between annoying and harmful to have to take extra steps to keep such intentional commits around. Granted, empty commits are quite rare, which is why handling of them doesn't get considered much and folks tend to defer to existing (accidental) behavior and assume there was a reason for it, leading them to just add flags (--keep-empty in this case) that allow them to override the bad defaults. Fix the interactive backend so that --keep-empty is the default, much like we did with --allow-empty-message. The am backend should also be fixed to have --keep-empty semantics for commits that start empty, but that is not included in this patch other than a testcase documenting the failure. Note that there was one test in t3421 which appears to have been written expecting --keep-empty to not be the default as correct behavior. This test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of empty commits", 2013-06-06), which was part of a series focusing on rebase topology and which had an interesting original cover letter at https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/ which noted Your input especially appreciated on whether you agree with the intent of the test cases. and then went into a long example about how one of the many tests added had several questions about whether it was correct. As such, I believe most the tests in that series were about testing rebase topology with as many different flags as possible and were not trying to state in general how those flags should behave otherwise. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

rebase-interactive: warn if commit is dropped with `rebase --edit-todo'

2020-01-28T22:14:57Z

When set to "warn" or "error", `rebase.missingCommitsCheck' would make `rebase -i' warn if the user removed commits from the todo list to prevent mistakes. Unfortunately, `rebase --edit-todo' and `rebase --continue' don't take it into account. This adds the ability for `rebase --edit-todo' and `rebase --continue' to check if commits were dropped by the user. As both edit_todo_list() and complete_action() parse the todo list and check for dropped commits, the code doing so in the latter is removed to reduce duplication. `edit_todo_list_advice' is removed from sequencer.c as it is no longer used there. This changes when a backup of the todo list is made. Until now, it was saved only once, before the initial edit. Now, it is also made if the original todo list has no errors or no dropped commits. Thus, the backup should be error-free. Without this, sequencer_continue() (`rebase --continue') could only compare the current todo list against the original, unedited list. Before this change, this file was only used by edit_todo_list() and `rebase -p' to create the backup before the initial edit, and check_todo_list_from_file(), only used by `rebase -p' to check for dropped commits after its own initial edit. If the edited list has an error, a file, `dropped', is created to report the issue. Otherwise, it is deleted. Usually, the edited list is compared against the list before editing, but if this file exists, it will be compared to the backup. Also, if the file exists, sequencer_continue() checks the list for dropped commits. If the check was performed every time, it would fail when resuming a rebase after resolving a conflict, as the backup will contain commits that were picked, but they will not be in the new list. It's safe to ignore this check if `dropped' does not exist, because that means that no errors were found at the last edition, so any missing commits here have already been picked. Five tests are added to t3404. The tests for `rebase.missingCommitsCheck = warn' and `rebase.missingCommitsCheck = error' have a similar structure. First, we start a rebase with an incorrect command on the first line. Then, we edit the todo list, removing the first and the last lines. This demonstrates that `--edit-todo' notices dropped commits, but not when the command is incorrect. Then, we restore the original todo list, and edit it to remove the last line. This demonstrates that if we add a commit after the initial edit, then remove it, `--edit-todo' will notice that it has been dropped. Then, the actual rebase takes place. In the third test, it is also checked that `--continue' will refuse to resume the rebase if commits were dropped. The fourth test checks that no errors are raised when resuming a rebase after resolving a conflict, the fifth checks that no errors are raised when editing the todo list after pausing the rebase. Signed-off-by: Alban Gruin Signed-off-by: Junio C Hamano

sequencer: move check_todo_list_from_file() to rebase-interactive.c

2020-01-28T22:13:41Z

The message contained in `edit_todo_list_advice' (sequencer.c) is printed after the initial edit of the todo list if it can't be parsed or if commits were dropped. This is done either in complete_action() for `rebase -i', or in check_todo_list_from_file() for `rebase -p'. Since we want to add this check when editing the list, we also want to use this message from edit_todo_list() (rebase-interactive.c). To this end, check_todo_list_from_file() is moved to rebase-interactive.c, and `edit_todo_list_advice' is copied there. In the next commit, complete_action() will stop using it, and `edit_todo_list_advice' will be removed from sequencer.c. Signed-off-by: Alban Gruin Signed-off-by: Junio C Hamano

rebase -i: also avoid SHA-1 collisions with missingCommitsCheck

2020-01-23T20:48:12Z

When `rebase.missingCommitsCheck` is in effect, we use the backup of the todo list that was copied just before the user was allowed to edit it. That backup is, of course, just as susceptible to the hash collision as the todo list itself: a reworded commit could make a previously unambiguous short commit ID ambiguous all of a sudden. So let's not just copy the todo list, but let's instead write out the backup with expanded commit IDs. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano