Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
for amending, I feel like changing the default behaviour is never going to happen. on the other hand, maybe I’ll eventually submit a patch to git to add an alternative squash mode…
in the meantime, I am using a very particular, manual process for all my git merges.
Richard Stephens
(replying to Kanbaru 🌟 (one hikari of too many))
@hikari when I am elected president, —amend will retain previous versions of the commit by default, and squash will be non-destructive.
2 replies
Kanbaru 🌟 (one hikari of too many)
(replying to Richard Stephens)
@richardstephens ooh, how would you do that?
Richard Stephens
(replying to Kanbaru 🌟 (one hikari of too many))
@hikari Instead of actually squashing, generate an empty commit with metadata that indicates "treat the past 7 commits as one squashed commit". Even better, bisect, could know to jump between only squashed commits.
1 replies
Kanbaru 🌟 (one hikari of too many)
(replying to Richard Stephens)
@richardstephens honestly it sounds to me like what you want are actual merges
Richard Stephens
(replying to Richard Stephens)
@hikari You could also make an "amended" commit actually a branch that's hidden from most of the UI. Both of these solutions would be backwards compatible too, although I freely admit to not having thought through all the implications.
Saagar Jha
(replying to Richard Stephens)
Richard Stephens
(replying to Saagar Jha)
@saagar @hikari where I’m coming from is that there’s often a trade off between “clean history with messy intermediate states discarded” and “all intermediate states kept but history is an unintelligible mess”. I think it would be neat if we could have tools that would only surface a clean curated view of history by default but also had the more detailed view available in the rare case it’s needed.