4 ms·

There are essentially two approaches: - History is sacred and can't be changed. It typically goes with a merge-based workflow. The good thing is that nothing i

by GuB-42 4y ago

There are essentially two approaches: - History is sacred and can't be changed. It typically goes with a merge-based workflow. The good thing is that nothing is lost, what you see is what really happened and you won't make a mess with inappropriate push --force. The downside is that it looks messy since you are going to see every typo and you will have some non functional code in your history. People using that workflow usually don't squash since squashing rewrites history. - History is like documentation and have to be nice and clean. It typically goes with a rebase-based workflow. This is what the article is about. The good thing is that every commit has working code, and git log can effectively replace a more formal change log. The downside is that you lose information and the git log doesn't represent what really happened, furthermore, since push --force is often used, your local branch may not be the branch you think you are on, you may even end up destroying other people commits. People using this workflow usually squash to make their commits nicer. I prefer the "history is sacred" workflow myself, but both options are valid.

__blockcipher__ 4y ago
It's ironic that the "history is sacred" crowd contains the people least likely to actually look at and use the git history to aid their contextual understanding of the codebase. Why do I say that? Well, because once you've come across a useless typo commit for the 12th time, you start to very quickly see how such commits needlessly bloat the history and make it far harder to understand (and make things like git blame much more unwieldy), while not actually offering any benefit. It doesn't matter to me at all 3 months later to know that you initially had a typo in your first commit and then fixed it the subsequent commit. That should just be a single commit. There are some very rare edge cases where having the whole messy history can offer some insight of how a certain mistake ended up being made, but IMO in 999/1000 cases that's not the case.
- Arelius 4y ago
  Squashing and rebasing don’t fix the shitty commit message problem. Discipline and good teamwork do. All to often in rebase+squash heavy repos I start going through the history and find the mega-commit that introduced a change and gain zero insight. In comparison, merge heavy repos have a lot of merge this, or fix this typo commits, that are fairly easy to skip right over when not pertaining to your actual change, but prove invaluable when the problem was introduced by some weird bad conflict resolution including a typo, or countless other problems where just all context is otherwise lost. I think it’s unfair to characterize one group as not using the history, but instead represent differences in how groups use them. As an archaeologist vs daily change log perhaps is a better characterization?
- GuB-42 4y ago
  That's why when you use a "history is sacred" approach, you typically have several branches and use merge commits, not rebase. When you look at the master branches you will mostly see merge commits, all the mess will be on the side, for example in feature branches. Merge commits can be clean, and when you are blaming, you will see the merge commit, not the dozen of typo commits. If you do "git log --first-parent" you will not even see the messy commits, but they will be there if you need them.
kazinator 4y ago
Projects should rewrite their public history from time to time, for instance to get rid of commits that never should have happened, or move changes between commits, fix commit messages and such. The history should be treated as the perfect object to develop. We should continuously revise how this program should have been developed to its current state, by what sequence of changes.
- GuB-42 4y ago
  While I think a rebase workflow where you rewrite the history of feature branches is a reasonable approach, rewriting public history is a big no for me. Maybe it is fine with some version control systems, but certainly not git. Git is essentially a blockchain, rewriting history is like rolling back a bitcoin transaction, it is impossible without breaking cryptography. Instead, when you rewrite history in git, you actually create a new project to replace the old one. You then have to tell everyone to switch to your "new project", otherwise you will create a lot of confusion and painful merges, if they don't decide to say "fuck you" and keep working with the original history. Git is decentralized, and to work it needs some consensus, and the consensus is in the history, if you break that, you break the decentralized nature of git. Now, if your don't open your repository to the general public and use git like you would use svn or other centralized systems, it is fine, but don't do that for public repositories.
  - kazinator 4y ago
    Rewriting public history is completely fine with git. Upstream says: "master is now this SHA, deal with it". Actively developing downstreams can easily rebase their stuff (if any) across non-fastforward changes, and life goes on. For a pure consumer of a repo, it makes no difference. There is only the cultural idea that it's a no-no, not a technical idea.

by GuB-42 4y ago

__blockcipher__ 4y ago

It's ironic that the "history is sacred" crowd contains the people least likely to actually look at and use the git history to aid their contextual understanding of the codebase. Why do I say that? Well, because once you've come across a useless typo commit for the 12th time, you start to very quickly see how such commits needlessly bloat the history and make it far harder to understand (and make things like git blame much more unwieldy), while not actually offering any benefit. It doesn't matter to me at all 3 months later to know that you initially had a typo in your first commit and then fixed it the subsequent commit. That should just be a single commit. There are some very rare edge cases where having the whole messy history can offer some insight of how a certain mistake ended up being made, but IMO in 999/1000 cases that's not the case.

Arelius 4y ago
Squashing and rebasing don’t fix the shitty commit message problem. Discipline and good teamwork do. All to often in rebase+squash heavy repos I start going through the history and find the mega-commit that introduced a change and gain zero insight. In comparison, merge heavy repos have a lot of merge this, or fix this typo commits, that are fairly easy to skip right over when not pertaining to your actual change, but prove invaluable when the problem was introduced by some weird bad conflict resolution including a typo, or countless other problems where just all context is otherwise lost. I think it’s unfair to characterize one group as not using the history, but instead represent differences in how groups use them. As an archaeologist vs daily change log perhaps is a better characterization?
GuB-42 4y ago
That's why when you use a "history is sacred" approach, you typically have several branches and use merge commits, not rebase. When you look at the master branches you will mostly see merge commits, all the mess will be on the side, for example in feature branches. Merge commits can be clean, and when you are blaming, you will see the merge commit, not the dozen of typo commits. If you do "git log --first-parent" you will not even see the messy commits, but they will be there if you need them.

kazinator 4y ago

Projects should rewrite their public history from time to time, for instance to get rid of commits that never should have happened, or move changes between commits, fix commit messages and such. The history should be treated as the perfect object to develop. We should continuously revise how this program should have been developed to its current state, by what sequence of changes.

GuB-42 4y ago
While I think a rebase workflow where you rewrite the history of feature branches is a reasonable approach, rewriting public history is a big no for me. Maybe it is fine with some version control systems, but certainly not git. Git is essentially a blockchain, rewriting history is like rolling back a bitcoin transaction, it is impossible without breaking cryptography. Instead, when you rewrite history in git, you actually create a new project to replace the old one. You then have to tell everyone to switch to your "new project", otherwise you will create a lot of confusion and painful merges, if they don't decide to say "fuck you" and keep working with the original history. Git is decentralized, and to work it needs some consensus, and the consensus is in the history, if you break that, you break the decentralized nature of git. Now, if your don't open your repository to the general public and use git like you would use svn or other centralized systems, it is fine, but don't do that for public repositories.
- kazinator 4y ago
  Rewriting public history is completely fine with git. Upstream says: "master is now this SHA, deal with it". Actively developing downstreams can easily rebase their stuff (if any) across non-fastforward changes, and life goes on. For a pure consumer of a repo, it makes no difference. There is only the cultural idea that it's a no-no, not a technical idea.