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

sequencer: rewrite update-refs as user edits todo list

2022-07-19T19:49:04Z

An interactive rebase provides opportunities for the user to edit the todo list. The --update-refs option initializes the list with some 'update-ref ' steps, but the user could add these manually. Further, the user could add or remove these steps during pauses in the interactive rebase. Add a new method, todo_list_filter_update_refs(), that scans a todo_list and compares it to the stored update-refs file. There are two actions that can happen at this point: 1. If a '//' triple in the update-refs file does not have a matching 'update-ref ' command in the todo-list _and_ the value is the null OID, then remove that triple. Here, the user removed the 'update-ref ' command before it was executed, since if it was executed then the value would store the commit at that position. 2. If a 'update-ref ' command in the todo-list does not have a matching '//' triple in the update-refs file, then insert a new one. Store the value to be the current OID pointed at by . This is handled inside of the init_update_ref_record() helper method. We can test that this works by rewriting the todo-list several times in the course of a rebase. Check that each ref is locked or unlocked for updates after each todo-list update. We can also verify that the ref update fails if a concurrent process updates one of the refs after the rebase process records the "locked" ref location. To help these tests, add a new 'set_replace_editor' helper that will replace the todo-list with an exact file. Reported-by: Phillip Wood Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

sequencer: add update-ref command

2022-07-19T19:49:03Z

Add the boilerplate for an "update-ref" command in the sequencer. This connects to the current no-op do_update_ref() which will be filled in after more connections are created. The syntax in the todo list will be "update-ref " to signal that we should store the current commit as the value for updating at the end of the rebase. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

rebase-interactive: update 'merge' description

2022-07-19T19:49:03Z

The 'merge' command description for the todo list documentation in an interactive rebase has multiple lines. The lines other than the first one start with dots ('.') while the similar multi-line documentation for 'fixup' does not. This description only appears in the comment text of the todo file during an interactive rebase. The 'merge' command was documented when interactive rebase was first ported to C in 145e05ac44b (rebase -i: rewrite append_todo_help() in C, 2018-08-10). These dots might have been carried over from the previous shell implementation. The 'fixup' command was documented more recently in 9e3cebd97cb (rebase -i: add fixup [-C | -c] command, 2021-01-29). Looking at the output in an editor, my personal opinion is that the dots are unnecessary and noisy. Remove them now before adding more commands with multi-line documentation. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

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