4 ms·

Squashing literally requires `git rebase`. Perhaps you think of squashing as a GitHub button and not a series of rewriting commands? Technically, any rewrite is

by sshine 4y ago

Squashing literally requires `git rebase`. Perhaps you think of squashing as a GitHub button and not a series of rewriting commands? Technically, any rewrite is equivalent to some arbitrary construction of history from some point in time, but I think a reasonable definition of rewriting history is if you need to rebase or cherry-pick when using the command-line.

cortesoft 4y ago
You can create a squash commit on the main branch while leaving the feature branch untouched.
dahart 4y ago
We don’t need a reasonable definition of rewriting history, we need a better conversation about what our tools are even for. Git isn’t a tool for preserving history, it’s a tool for keeping track of code changes. Git rebase provides a new, second, altered sequence of commits. It doesn’t replace the original. We often choose to preserve the rebased sequence, but this distinction is not academic, it’s critically important because as a part of a version control system, rebase can be undone, precisely because it does not write over the old history. Git never promised a “history” per se, not in the form of an immutable record of events. The framing of git rebase as a history rewrite, the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git. I’m in favor of better VCSs, but the claim that rebase is a history rewrite is hyperbolic, and the judgement on top of that is silly and misguided. Rebase is a tool designed to reorder a sequence of commits, mostly for the purposes of making local changes presentable before pushing them, and has other legitimate uses too.
- sshine 4y ago
  > rebase can be undone, precisely because it does not write over the old history Good point. Perhaps "rewrite history" is not the best metaphor, and does not cover all possible git workflows. I only considered the workflows where a rebased branch is merged back onto master instead of its non-rebased variant, which loses its name, its remote copy/copies and is eventually hit by the GC. > the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git. The resistance I've met among developers to adopt rebasing workflows with git have no knowledge of Fossil. My impression is that the main objection to such workflows is that it exceeds some developers' novelty budget [0] and that those developers generally don't read git messages and don't value the history of code to understand its current shape. [0]: https://shimweasel.com/2018/08/25/novelty-budgets https://shimweasel.com/2018/08/25/novelty-budgets
  - dahart 4y ago
    Sorry maybe I got a little ranty there. Rewrite history is an okay metaphor, not great but nothing super wrong with it as an approximation. And you're totally right, there is definitely resistance to rebase outside of Fossil, and even within the git community with people who've never heard of Fossil. Git does have a steep learning curve and a bumpy interface that most people (including yours truly) never get all the way through. FWIW, my intro to rebase came after using Perforce for years. Because git is strict about commit ordering and P4 is not, I was struggling to figure out how to manage multiple in-flight changes like I would in P4, and how to clean up and push something that wasn't a hot mess. Rebasing my local workspace, it turned out, is the answer to that. It is the key to working around git's strict commit parentage, and makes it easy to sculpt changes so they're palatable for me and my team. Above I was referring to some of the anti-rebase messaging Fossil has put out in the past. Some is there still, for example https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md I'm quite pleased to see that a lot of the most hyperbolic verbiage is gone now, it used to carry on quite a bit. But that page still says rebase is "dishonest", which is a deeply ironic claim, if you catch my drift. That kind of mis-representation ruffles my feathers a little bit, but I've had discussions with the Fossil team right here on HN about it, and they have in fact been open to listening, responsive, and willing to change and improve the messaging.

by sshine 4y ago

cortesoft 4y ago

You can create a squash commit on the main branch while leaving the feature branch untouched.

dahart 4y ago

We don’t need a reasonable definition of rewriting history, we need a better conversation about what our tools are even for. Git isn’t a tool for preserving history, it’s a tool for keeping track of code changes. Git rebase provides a new, second, altered sequence of commits. It doesn’t replace the original. We often choose to preserve the rebased sequence, but this distinction is not academic, it’s critically important because as a part of a version control system, rebase can be undone, precisely because it does not write over the old history. Git never promised a “history” per se, not in the form of an immutable record of events. The framing of git rebase as a history rewrite, the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git. I’m in favor of better VCSs, but the claim that rebase is a history rewrite is hyperbolic, and the judgement on top of that is silly and misguided. Rebase is a tool designed to reorder a sequence of commits, mostly for the purposes of making local changes presentable before pushing them, and has other legitimate uses too.

sshine 4y ago
> rebase can be undone, precisely because it does not write over the old history Good point. Perhaps "rewrite history" is not the best metaphor, and does not cover all possible git workflows. I only considered the workflows where a rebased branch is merged back onto master instead of its non-rebased variant, which loses its name, its remote copy/copies and is eventually hit by the GC. > the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git. The resistance I've met among developers to adopt rebasing workflows with git have no knowledge of Fossil. My impression is that the main objection to such workflows is that it exceeds some developers' novelty budget [0] and that those developers generally don't read git messages and don't value the history of code to understand its current shape. [0]: https://shimweasel.com/2018/08/25/novelty-budgets https://shimweasel.com/2018/08/25/novelty-budgets
- dahart 4y ago
  Sorry maybe I got a little ranty there. Rewrite history is an okay metaphor, not great but nothing super wrong with it as an approximation. And you're totally right, there is definitely resistance to rebase outside of Fossil, and even within the git community with people who've never heard of Fossil. Git does have a steep learning curve and a bumpy interface that most people (including yours truly) never get all the way through. FWIW, my intro to rebase came after using Perforce for years. Because git is strict about commit ordering and P4 is not, I was struggling to figure out how to manage multiple in-flight changes like I would in P4, and how to clean up and push something that wasn't a hot mess. Rebasing my local workspace, it turned out, is the answer to that. It is the key to working around git's strict commit parentage, and makes it easy to sculpt changes so they're palatable for me and my team. Above I was referring to some of the anti-rebase messaging Fossil has put out in the past. Some is there still, for example https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md I'm quite pleased to see that a lot of the most hyperbolic verbiage is gone now, it used to carry on quite a bit. But that page still says rebase is "dishonest", which is a deeply ironic claim, if you catch my drift. That kind of mis-representation ruffles my feathers a little bit, but I've had discussions with the Fossil team right here on HN about it, and they have in fact been open to listening, responsive, and willing to change and improve the messaging.