Charvi Mendiratta <charvi077@xxxxxxxxx> writes:
> `git commit --fixup=reword:<commit>` creates an empty "amend!" commit
> that will reword <commit> without changing its contents when it is
> rebased with --autosquash.
>
> Apart from ignoring staged changes it works similarly to
> `--fixup=amend:<commit>`.
>
> Example usage:
> $ git commit --fixup=reword:HEAD~3
> $ git commit --fixup=reword:HEAD~3 -m "new commit message"
The same comment applies to the above as an earlier step.
> +static void check_fixup_reword_options(void) {
> + if (whence != FROM_COMMIT) {
> + if (whence == FROM_MERGE)
> + die(_("You are in the middle of a merge -- cannot reword."));
> + else if (is_from_cherry_pick(whence))
> + die(_("You are in the middle of a cherry-pick -- cannot reword."));
> + }
> + if (all)
> + die(_("cannot combine reword option of --fixup with --all"));
> + if (also)
> + die(_("cannot combine reword option of --fixup with --include"));
> + if (only)
> + die(_("cannot combine reword option of --fixup with --only"));
> +}
Not just these options, wouldn't it be an error to ask to commit
anything but an empty commit? E.g. shouldn't this sequence
edit builtin/commit.c
git commit --fixup=reword:HEAD~3 -- builtin/commit.c
trigger an error, as we will *not* be taking any change made to the
working tree file?
Or is that implicitly covered by some other code?
In any case, we'd need a test for that (this is just a mental note
for myself---I haven't finished reading the series to the end, so
you may have one already).
Thanks.
