Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx/ >> >> >> [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.