On Tue, Jul 12, 2022 at 01:07:00PM +0000, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee <derrickstolee@xxxxxxxxxx>
>
> When working on a large feature, it can be helpful to break that feature
> into multiple smaller parts that become reviewed in sequence. During
> development or during review, a change to one part of the feature could
> affect multiple of these parts. An interactive rebase can help adjust
> the multi-part "story" of the branch.
>
> However, if there are branches tracking the different parts of the
> feature, then rebasing the entire list of commits can create commits not
> reachable from those "sub branches". It can take a manual step to update
> those branches.
>
> Add a new --update-refs option to 'git rebase -i' that adds 'update-ref
> <ref>' steps to the todo file whenever a commit that is being rebased is
> decorated with that <ref>. At the very end, the rebase process updates
> all of the listed refs to the values stored during the rebase operation.
>
> Be sure to iterate after any squashing or fixups are placed. Update the
> branch only after those squashes and fixups are complete. This allows a
> --fixup commit at the tip of the feature to apply correctly to the sub
> branch, even if it is fixing up the most-recent commit in that part.
>
> One potential problem here is that refs decorating commits that are
> already marked as "fixup!" or "squash!" will not be included in this
> list. Generally, the reordering of the "fixup!" and "squash!" is likely
> to change the relative order of these refs, so it is not recommended.
> The workflow here is intended to allow these kinds of commits at the tip
> of the rebased branch while the other sub branches come along for the
> ride without intervention.
>
> This change update the documentation and builtin to accept the
> --update-refs option as well as updating the todo file with the
> 'update-ref' commands. Tests are added to ensure that these todo
> commands are added in the correct locations.
>
> This change does _not_ include the actual behavior of tracking the
> updated refs and writing the new ref values at the end of the rebase
> process. That is deferred to a later change.
>
> Signed-off-by: Derrick Stolee <derrickstolee@xxxxxxxxxx>
> ---
> Documentation/git-rebase.txt | 8 +++
> builtin/rebase.c | 5 ++
> sequencer.c | 107 ++++++++++++++++++++++++++++++++++
> sequencer.h | 1 +
> t/t2407-worktree-heads.sh | 22 +++++++
> t/t3404-rebase-interactive.sh | 70 ++++++++++++++++++++++
> 6 files changed, 213 insertions(+)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 262fb01aec0..e7611b4089c 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -609,6 +609,13 @@ provided. Otherwise an explicit `--no-reschedule-failed-exec` at the
> start would be overridden by the presence of
> `rebase.rescheduleFailedExec=true` configuration.
>
> +--update-refs::
So the option is called '--update-refs', but ...
> +--no-update-refs::
> + Automatically force-update any branches that point to commits that
... its description talks about "branches".
> + are being rebased. Any branches that are checked out in a worktree
> + or point to a `squash! ...` or `fixup! ...` commit are not updated
> + in this way.
> +
> INCOMPATIBLE OPTIONS
> --------------------
>
> @@ -1124,6 +1126,9 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
> OPT_BOOL(0, "autosquash", &options.autosquash,
> N_("move commits that begin with "
> "squash!/fixup! under -i")),
> + OPT_BOOL(0, "update-refs", &options.update_refs,
> + N_("update local refs that point to commits "
And its short help talks about "local refs".
I think at least the documentation and short help should use
consistent terminology.
> + "that are being rebased")),
> { OPTION_STRING, 'S', "gpg-sign", &gpg_sign, N_("key-id"),
> N_("GPG-sign commits"),
> PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
