Re: Bug with fixup and autosquash

[Junio C Hamano <gitster@pobox.com>]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Junio C Hamano venit, vidit, dixit 08.02.2017 23:55:
>
>> Let's hear from some of those (Cc'ed) who were involved in an
>> earlier --autosquash thread.
>> 
>> https://public-inbox.org/git/cover.1259934977.git.mhagger@alum.mit.edu/
>> 
>> 
>> [Footnote]
>> 
>> *1* "rebase -i --autosquash" does understand "fixup! yyyyyy", so if
>>     you are willing to accept the consequence of not being able to
>>     rebase twice, you could instead do
>> 
>> 	$ git commit -m "fixup! yyyyyy"
>> 
>>     I would think.
>
> Doesn't this indicate that rebase is fine as is?

Not really, unless you ignore "if you are willing to accept" part,
which actually is a big downside.  And --fixup-fixed will make it
worse, unfortunately.

> - teach "git commit --fixup=<rev>" to check for duplicates (same prefix,
> maybe only in "recent" history) and make it issue a warning, say:

This is a very good idea worth pursuing, and (I didn't think things
through, though) we may even be able to bound "recent" without
heuristics---scanning between <rev> and the tip for duplicates might
be sufficient.

> Additionally, we could teach commit --fixup-fixed to commit -m "fixup!
> <sha1> <prefix>" so that we have both uniqueness and verbosity in the
> rebase-i-editor. This would allow "rebase -i" to fall back to the old
> mode when "<sha1>" is not in the range it operates on.

This is also a possibility, but it needs cooperation between both
"commit" and "rebase -i".

I personally do not think rewriting "fixup! yyyyyy" on the title
during rebase is worth doing, but that is not because I have a
concrete reason against it but it just sounds like too much magic to
my gut feeling.  Perhaps it can be done reliably with minimal change
to the code.  I dunno.

Thanks.