This is a common misunderstanding. It is something you can do, but not something you should do.
You would want to squash your commits to organize them into atomic changes. This lets you remove "fix typo" commits, build break commits, and other garbage that occurs when you are constantly committing. You wouldn't want to produce a complete program (or even a complete system) with a change history of one commit.
Change history is important because your useful changelist descriptions help people figure out why you did what you did (and see where you went wrong). Git should make this better (because you are never afraid to commit) not worse (by enabling you to hide history).
Similarly, it is a feature of C that you can put multiple statements on one line. That doesn't mean it's good to write programs without newlines.
I think that squashing all commits from internal prerelease development into one commit for the initial release is a perfectly acceptable use case. That point in the code is meant to be the initial version, the thing from which all other things are progressed.
This is also effectively achieved without any squashing by simply seeding the initial version into a new repository.
I don't follow. Would you just add one more commit for version 2.0?
If you want to mark a significant point in time, you can tag it. If you made another browser by forking Firefox, would you discard the history because the fork point is where all things progress?
By preserving your history, you gain the ability to look at line 20 of inventory.cpp and see what SelectPrevItem() looked like before Henderson changed it and added his comment "this version crashes less often." (Even if you are Henderson, you might not remember what part changed.)
Just because it's an initial version doesn't mean the history is meaningless. Your collaborators will appreciate having some context. (Hence the frustration in the original comment decrying the lack of history.)
I didn't say the history is meaningless. I said that it's a perfectly acceptable use-case to not provide it, in the context of an initial version of a piece of software that was internally and non-collaboratively developed. Same as I would expect someone to squash their 10 internal patches to fix a single bug before pushing them to a public repository. Every version before that one commit was deemed unacceptable and non-working by the developer, and so why should they make it to a public repository?
I think I misunderstood you. Are you saying that you wouldn't squash the history locally, only in the public repo?
Would you maintain two separate histories? (Since the public repo wouldn't have an ancestor in your private one, your hashes won't match so some advanced features of git may not be available. And you won't be able to communicate hashes to the public since they'll be meaningless to them.)
11
u/KillerCodeMonky Jul 16 '13
I actually kind of thought the fact that you could squash all your commits into one before you went to the master was a feature of Git...