Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm curious how your commit history looks. Doesn't it have tons of useless commits like "removing comments", "forgot semicolon" etc?

Here's Linus Torvalds' thoughts on rebasing. https://yarchive.net/comp/linux/git_rebase.html



I agree with Linus, "you really shouldn't rebase stuff that has been exposed anywhere outside of your own private tree"

I have no problem if you want to locally squash your commits. Just don't rewrite public history. It's not worth it. At our commit rate, no one is reading the combined history logs without filters first.


You never run git log on a single file or directory?


That would qualify as a filter...


Yes. And it should. It's your commit history, so it needs to be a history of your commits.

One day you'll find a commit labeled "removing comments" that breaks something because the dev palmed the trackpad while hitting the delete key and lopped off a line of code. You want that to be something you can find with a bisect.

It amazes me to see a bunch of discussion here from people arguing that one should throw away history so that some silly graph view is prettier.

History isn't meant to be pretty. It's meant to be history.


Those aren't his thoughts on rebasing, they're his thoughts on rebasing "somebody else's work".


I don’t rebase and I don’t have these sorts of commits. I do use commit —amend when I see a typo in code I just checked in, though, and git stash if I need to set my current task aside for a moment to fix or prepare something else.


Very rarely, I undo and redo a commit to fix a problem with it, in cases that are too complex for --amend.

But once history has been shared (pushed, generally), it really shouldn't be touched anymore.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: