On Fri, 14 Dec 2018, Oliver Joseph Ash wrote:

> I believe I have found a bug in `git commit --fixup`.
>
> Steps to reproduce:
> 1. Create a git history with two commits (A and B) with the same
> commit message (e.g. foo)

> 2. Create a new commit using `git commit --fixup {SHA}`, referring to
> the last commit SHA
> 3. Run an interactive rebase
>
> Expected: the fixup commit should appear below the last commit in the todo 
> list.

Perhaps another useful behavior, when the ambiguity exists (i.e. absent
the trailer Rafael suggested), would be to keep the existing behavior
but notify the user, and point to a new section in the docs on the
subject:


pick aaaa foo
fixup dddd fixup! foo
pick bbbb foo
# ambiguous autosquash: dddd may have targeted bbbb instead of aaaa.
pick cccc unrelated

# Rebase 0000..dddd onto 0000 (4 commands)
# This rebase includes one or more ambiguous autosquashes.
# See git help rebase for more information (under AMBIGUOUS AUTOSQUASH)
#
# Commands:
# (etc)

On Fri, Dec 14, 2018 at 9:00 AM Rafael Ascensão <rafa.al...@gmail.com> wrote:
>
> On Fri, Dec 14, 2018 at 12:30:28PM +0000, Oliver Joseph Ash wrote:
> > I believe I have found a bug in `git commit --fixup`.
>
> That's not a bug, it's actually the documented behaviour of rebase
> --autosquash.
>
> As you figured out, the squash/fixup is based on whether the message
> has the squash!/fixup! prefix and the subject matches. But it also
> allows specifying hashes.
>
> So for fixups, you can be explicit and use: git commit -m 'fixup! SHA'.
>
> Similarly for squashes. (But a little less friendly as you'll need to
> deal with passing an argument to -m that contains newlines).
>
> But adding 'squash! SHA' when the editor opens should also work.
>
> I believe the main reason this works based on subject message matching
> is to be more friendly with scenarios where you're sharing series of
> commits that include fixups and squashes. (Either via format patch, or
> by rebasing the series on a newer base without --autosquash).
>
> On such cases the commit you're trying to fixup will have a different
> OID, so any hardcoded OID will be useless while commit message matching
> works most of the time.
>
> One potential improvement to this is to teach --fixup and --squash to
> also add trailers like: "{fixup,squash}: SHA" or "target: SHA" and teach
> --autosquash to respect it when possible.
>
> Thoughts?

I like very much the proposal to use trailers to indicate the intended target.
"target: SHA" would probably be better. It could be used for a first pass and
if no match is found (in case of rebase or patch-by-mail) or the trailer is not
present, fall back to the default approach of matching by subject line and
noting other potential matches as described above).

Reply via email to