Re: Bug with fixup and autosquash
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 9, 2017, 19:46 UTC
- Message-ID
- <xmqqpoirp2or.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <07eb2367-9509-afb0-2494-f02a44304bc4@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 19 quoted lines
> 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.