Kanbaru 🌟 (one hikari of too many)
a thing that really irks me about git: the “author date” in commits. imho, if you make non-trivial changes to a commit when amending it, you should update that date; and if you squash several commits together, you should use the date of the latest one. neither is the default…
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
git commit --amend defaults to not changing the author date. that’s reasonable for minor changes, but in an environment where people work with commits rather than branches (e.g. Gerrit), this means commit dates that are days, weeks or months earlier than most of the changes…
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
you can use --reset-author when editing a commit, but not many people seem to know of that.
meanwhile using git merge --squash to do a squash merge of someone else’s work makes you the author now, and makes the date the current time. I don’t like that either.
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.