Hacker News new | past | comments | ask | show | jobs | submit login

I'm not the person you asked, but I think they meant: changes that are not shared with others. You can back up your own stuff as you please, but once you share it with someone else, it's best to treat that bit of repo history as immutable from that point onward (because they may have made their own copies, shared it with other people, etc).

So I think what people are saying (and I largely agree with them) is that it's fine to rewrite history as long as you never share the ugly mess that existed before the rewrite with others.

A typical example of this is having un-shared ("local" - but could be backed up) streams of "tweak a comment, fix a semicolon, xxx" changesets that aren't really going to be useful to other people. Before you share with others, you squash them down to a single (or few) "implement feature X" kind of changes, often with linear history.

Having that less-branchy and less-noisy linear history available is useful in the future when you want to examine the history of the repo. Future people don't need to know that you fixed a comment, added a semicolon, etc. They want to know the big coherent logical changes that were applied to the repo.

Squasing/rebasing/fixing history before you share it allows you to have your cake and eat it too, more or less.

----

EDIT: Here's a decent email from Torvalds on the subject (not that I agree w/him about everything, but in this case): https://www.mail-archive.com/dri-devel@lists.sourceforge.net...




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: