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).