3 ms·

"Clean history" is not a principal reason for VCS. "Full history so you don't accidentally lose something and can revert to any point" is the principal reason.

"Clean history" is not a principal reason for VCS. "Full history so you don't accidentally lose something and can revert to any point" is the principal reason. When "clean history" conflicts with "full history", the choice should always defer to the latter. Rebase clearly breaks the full history principle.

paulddraper 3y ago
Part of not losing stuff and reverting is being able to find stuff and precisely revert.
rhinoceraptor 3y ago
There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word. If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well prepared, atomic changes where at each point the software is actually functional.
- naasking 3y ago
  Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.
  - seba_dos1 3y ago
    There are a lot of reasons to make a commit other than wanting to make an atomic change meant to be integrated onto shared repository. Ignoring those is just silly.
    - naasking 3y ago
      I agree 100%, and never said otherwise, but this seems like an orthogonal point to what we're discussing here.
  - rhinoceraptor 3y ago
    I make a commit whenever I want to save my progress, and rarely is it ever in a state that could even be called a "version" of the software that one would want to revert to, until my feature branch is complete and ready for code review. At that point I have a much better idea of the scope of my changes, and I can revise them into a few coherent commits, rather than a mess of "WIP" commits that are not a useful history to keep.
    - naasking 3y ago
      > and I can revise them into a few coherent commits, Why bother with this step at all? It's literally pointless and serves only to stroke an (IMO) silly aesthetic preference. > rather than a mess of "WIP" commits that are not a useful history to keep. I also disagree that WIP commits are not useful history. You might have explored 2 or 3 different abstractions to solve a problem, and picked one but it turned out to be the wrong one, and one of the others would have been a better choice, but now you've lost the history where you explored these options. Are you suggesting it's no loss to erase those other commits and the context around which you thought it wasn't a good choice at the time?
seba_dos1 3y ago
The principal reason for VCS has nothing to do with "history" at all. It has all to do with "versions". What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time. When you hack on some codebase and throw things at wall to see what sticks, you want to be able to go back to the previous attempt should your next one turn out to be useless. You may even want to commit things just because it's a convenient way to send things to be built by CI - so you basically produce "versions" to test. But when you collaborate with others to develop a project, nobody cares about whether you made typos during your hacking session and had to come back to fix them. It's not a useful information and it never becomes a "version" of a shared project, because why would it? It's just confusing and wastes people's time on review, and makes things like blame and bisect harder to use. Or when you put a tutorial under a git repo, with each commit representing the next step to achieve a certain outcome. You may have tweaked each step gazillion of times to perfect it, but that "history" is completely irrelevant for the resulting repo. It's meant to store "versions", not "history". Those may correlate, but don't have to. A git repo is a data structure that you operate on. Treat it as such and use to achieve your goals. What's funny is that "squash on merge" strategy gets you worst of both worlds. You don't get nicely curated versions in your project because if someone actually cared to fine-tune their MR you just throw that information away, and the rest doesn't care in the first place anyway. Rebasing and squashing is an incredibly useful tool for everyday use by developers in their work, but it often gets used as a band-aid for lazy developers instead.
- naasking 3y ago
  > What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time. In other words, the history. > It's not a useful information and it never becomes a "version" of a shared project, because why would it? Because the real world doesn't match your ideal of how software development works. You need the full history because sometimes innocuous looking "simple fixes" are neither innocuous nor fixes, and because obscuring the history makes auditing and merges more difficult, not less. > It's just confusing and wastes people's time on review, and makes things like blame and bisect harder to use. So blame and bisect are poorly written therefore you should hack around them using a convoluted process that obscures the true history and raises the risk of requiring people to redo weeks worth of work by overwriting branch histories on shared repos. Great idea. The authors of Fossil and Sqlite did a complete breakdown of everything wrong with rebase and what a proper tool should do, so I won't belabour the point further: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

paulddraper 3y ago

Part of not losing stuff and reverting is being able to find stuff and precisely revert.

rhinoceraptor 3y ago

There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word. If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well prepared, atomic changes where at each point the software is actually functional.

naasking 3y ago
Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.
- seba_dos1 3y ago
  There are a lot of reasons to make a commit other than wanting to make an atomic change meant to be integrated onto shared repository. Ignoring those is just silly.
  - naasking 3y ago
    I agree 100%, and never said otherwise, but this seems like an orthogonal point to what we're discussing here.
- rhinoceraptor 3y ago
  I make a commit whenever I want to save my progress, and rarely is it ever in a state that could even be called a "version" of the software that one would want to revert to, until my feature branch is complete and ready for code review. At that point I have a much better idea of the scope of my changes, and I can revise them into a few coherent commits, rather than a mess of "WIP" commits that are not a useful history to keep.
  - naasking 3y ago
    > and I can revise them into a few coherent commits, Why bother with this step at all? It's literally pointless and serves only to stroke an (IMO) silly aesthetic preference. > rather than a mess of "WIP" commits that are not a useful history to keep. I also disagree that WIP commits are not useful history. You might have explored 2 or 3 different abstractions to solve a problem, and picked one but it turned out to be the wrong one, and one of the others would have been a better choice, but now you've lost the history where you explored these options. Are you suggesting it's no loss to erase those other commits and the context around which you thought it wasn't a good choice at the time?

seba_dos1 3y ago

The principal reason for VCS has nothing to do with "history" at all. It has all to do with "versions". What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time. When you hack on some codebase and throw things at wall to see what sticks, you want to be able to go back to the previous attempt should your next one turn out to be useless. You may even want to commit things just because it's a convenient way to send things to be built by CI - so you basically produce "versions" to test. But when you collaborate with others to develop a project, nobody cares about whether you made typos during your hacking session and had to come back to fix them. It's not a useful information and it never becomes a "version" of a shared project, because why would it? It's just confusing and wastes people's time on review, and makes things like blame and bisect harder to use. Or when you put a tutorial under a git repo, with each commit representing the next step to achieve a certain outcome. You may have tweaked each step gazillion of times to perfect it, but that "history" is completely irrelevant for the resulting repo. It's meant to store "versions", not "history". Those may correlate, but don't have to. A git repo is a data structure that you operate on. Treat it as such and use to achieve your goals. What's funny is that "squash on merge" strategy gets you worst of both worlds. You don't get nicely curated versions in your project because if someone actually cared to fine-tune their MR you just throw that information away, and the rest doesn't care in the first place anyway. Rebasing and squashing is an incredibly useful tool for everyday use by developers in their work, but it often gets used as a band-aid for lazy developers instead.

naasking 3y ago
> What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time. In other words, the history. > It's not a useful information and it never becomes a "version" of a shared project, because why would it? Because the real world doesn't match your ideal of how software development works. You need the full history because sometimes innocuous looking "simple fixes" are neither innocuous nor fixes, and because obscuring the history makes auditing and merges more difficult, not less. > It's just confusing and wastes people's time on review, and makes things like blame and bisect harder to use. So blame and bisect are poorly written therefore you should hack around them using a convoluted process that obscures the true history and raises the risk of requiring people to redo weeks worth of work by overwriting branch histories on shared repos. Great idea. The authors of Fossil and Sqlite did a complete breakdown of everything wrong with rebase and what a proper tool should do, so I won't belabour the point further: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md