4 ms·

> Once you git push (or in theory someone pulls from your repo, but people who pull from a working repo often deserve what they get) your changes to the authori

> Once you git push (or in theory someone pulls from your repo, but people who pull from a working repo often deserve what they get) your changes to the authoritative upstream repository or otherwise make the commits or tags publicly visible, you should ideally consider those commits etched in diamond for all eternity. I've broken this rule multiple times per day for the past 10 years. On your own feature branches, rebase your fucking shit and force push. I see so many people creating ungodly messes because they never want to erase the history of PRs that they've submitted and its just a nightmare of merge commits pulled back into their branch from master. I've watched a decade of git n00bs practice this "never under any circumstances rewrite history" advice and it fucks them up over and over and over again. Nobody actually cares about the exactly commit process you went through to fix the bug. Squash everything and rebase. Leave a SUMMARY of why you did what you did in the PR and/or commit message. Humans have this amazing ability to write stories about what they did after the fact. I'll frequently leave my-future-self notes on closed and merged PRs as I think about them post-merge, where I document what approaches were rejected, and what approaches might be worthwhile if the change isn't sufficient. Stuff like "I could not do WWWW because of <great sadness>, so instead we must do XXXX, if this is not sufficient because <unlikely edge condition turns out to be not so unlikely after all> then we must consider that YYYYY will be less preferable due to <stuff i was thinking about hard> and we should consider doing ZZZZZ first". If all you do is capture "what did I change" and don't capture your thinking and what you view to be all the different alternatives while your mind is still fresh with the problem then you're just throwing away useful information, which is what the "preserve your git history" approach does. In the future, when I read my PRs I just don't care about how I got there. I care about what I was thinking about. So I write down, long-form, what I was thinking about. A git history is about going from A to B, it might document why you bailed on going to C, but it probably doesn't capture the stuff you rejected the whole time like D E and F and why. And really I'd PREFER to read a good note on why C sucked as a solution. I don't need to see the code that went down the route of C until it turned into a mess and then had to be backed out.

xyzzy_plugh 5y ago
> On your own feature branches, rebase your fucking shit and force push. I see so many people creating ungodly messes because they never want to erase the history of PRs that they've submitted and its just a nightmare of merge commits pulled back into their branch from master. Strong agree. This is probably my sole complaint about Git, in that changes to branches are not tracked through history in an accessible manner. Being able to see "revisions" of a branch would be very useful, rather than erasing history. Gerrit works around this with metadata in the commit message but it would be nice for this to be a first class citizen. Knowing when branches were modified and by whom would be very useful -- author and committee fields are insufficient.
dahart 5y ago
I interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using. Otherwise I totally agree with you; git was designed with rebase use in mind. There’s a misleading meme about rebase being a “lie” that just can’t die soon enough. It’s done more damage than good. The problem is that it’s specious - tempting, persuasive, and easy to believe, even if it’s wrong and/or misguided - and the narrative of rebase being bad is supported and spread by respectable people like SQLite’s author. What some people don’t consider is that the story about rebase being harmful is frequently a sales pitch for a different DVCS entirely - the message isn’t to not rebase, it’s to not use git. Don’t rebase public/main branches (except in emergencies). Do rebase your local work before push. If using rebase in feature branches, use it (along with communication) in inverse proportion to how many other people are using it, because they have to force pull and so nobody stomps on anyone’s work. The idea that the exact order of every character typed is sacrosanct and should be immutable is strange. But there is a valid point behind some of the rebase criticism, which is that git does not have the best facilities for controlling how history is presented, and if it did, rebase might not be needed to the same degree that it is now. Some DVCSs are designing ways to have a plumbing history, and a separate porcelain history, to use git terminology. That seems like a genuinely good idea, and maybe in the future git can incorporate something like it.
- lamontcg 5y ago
  > I interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using. But "or otherwise make the commits or tags publicly visible" is written very broadly.
HWR_14 5y ago
I understand using squash. I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" and disagreeing on the value of seeing what happened in parallel?
- CRConrad 5y ago
  > I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" [...]? No, AIUI it's more about keeping logically related commits closer together. And also avoiding or minimizing merge conflicts, if you remember to rebase your feature branch back onto master/main periodically before merging it back in. (Half expecting a run-in with Cunningham's Law here.)
  - HWR_14 5y ago
    The second example still seems strange - couldn't you just merge the master onto the feature branch to bring it up to date? I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together. But maybe I'm just quite confused.
    - CRConrad 5y ago
      > couldn't you just merge the master onto the feature branch to bring it up to date? > I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together. They're related: I meant for the case where you don't (or only lightly) squash your history, so you get several commits from your branch. Maybe if you do regular merges, they're all jumbled up chronologically with whatever else has been merged into master/main in the mean time? Whereas re-base makes it seem that everything in your branch has come "on top of" whatever the current state of m/m is. So when you then later merge your branch back in, all your (possibly compressed into somewhat fewer) commits come as a neat little chain of their own, not interspersed with others? As I said, I may be wrong as fuck here. Feels intuitively right, but intuition often leads us wrong with software (and other logic), especially such famously non-intuitive stuff as git... But that whole thing of "re-base puts all commits in your branch 'on top of' the branch you base(d?) it on" is how I've understood all descriptions of the "rebase" command I've seen. And it's the only way I can make sense of the whole idea -- because otherwise, as you say, it would be the ssame thing as ordinary merges back-and-forth; no need for a separate name for the same thing. (So if you're going to squash the history of your branch down to a single commit anyway, maybe it makes no difference [except possibly for where in the chronological order it goes]? But don't quote me on that either.)

xyzzy_plugh 5y ago

> On your own feature branches, rebase your fucking shit and force push. I see so many people creating ungodly messes because they never want to erase the history of PRs that they've submitted and its just a nightmare of merge commits pulled back into their branch from master. Strong agree. This is probably my sole complaint about Git, in that changes to branches are not tracked through history in an accessible manner. Being able to see "revisions" of a branch would be very useful, rather than erasing history. Gerrit works around this with metadata in the commit message but it would be nice for this to be a first class citizen. Knowing when branches were modified and by whom would be very useful -- author and committee fields are insufficient.

dahart 5y ago

I interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using. Otherwise I totally agree with you; git was designed with rebase use in mind. There’s a misleading meme about rebase being a “lie” that just can’t die soon enough. It’s done more damage than good. The problem is that it’s specious - tempting, persuasive, and easy to believe, even if it’s wrong and/or misguided - and the narrative of rebase being bad is supported and spread by respectable people like SQLite’s author. What some people don’t consider is that the story about rebase being harmful is frequently a sales pitch for a different DVCS entirely - the message isn’t to not rebase, it’s to not use git. Don’t rebase public/main branches (except in emergencies). Do rebase your local work before push. If using rebase in feature branches, use it (along with communication) in inverse proportion to how many other people are using it, because they have to force pull and so nobody stomps on anyone’s work. The idea that the exact order of every character typed is sacrosanct and should be immutable is strange. But there is a valid point behind some of the rebase criticism, which is that git does not have the best facilities for controlling how history is presented, and if it did, rebase might not be needed to the same degree that it is now. Some DVCSs are designing ways to have a plumbing history, and a separate porcelain history, to use git terminology. That seems like a genuinely good idea, and maybe in the future git can incorporate something like it.

lamontcg 5y ago
> I interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using. But "or otherwise make the commits or tags publicly visible" is written very broadly.

HWR_14 5y ago

I understand using squash. I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" and disagreeing on the value of seeing what happened in parallel?

CRConrad 5y ago
> I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" [...]? No, AIUI it's more about keeping logically related commits closer together. And also avoiding or minimizing merge conflicts, if you remember to rebase your feature branch back onto master/main periodically before merging it back in. (Half expecting a run-in with Cunningham's Law here.)
- HWR_14 5y ago
  The second example still seems strange - couldn't you just merge the master onto the feature branch to bring it up to date? I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together. But maybe I'm just quite confused.
  - CRConrad 5y ago
    > couldn't you just merge the master onto the feature branch to bring it up to date? > I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together. They're related: I meant for the case where you don't (or only lightly) squash your history, so you get several commits from your branch. Maybe if you do regular merges, they're all jumbled up chronologically with whatever else has been merged into master/main in the mean time? Whereas re-base makes it seem that everything in your branch has come "on top of" whatever the current state of m/m is. So when you then later merge your branch back in, all your (possibly compressed into somewhat fewer) commits come as a neat little chain of their own, not interspersed with others? As I said, I may be wrong as fuck here. Feels intuitively right, but intuition often leads us wrong with software (and other logic), especially such famously non-intuitive stuff as git... But that whole thing of "re-base puts all commits in your branch 'on top of' the branch you base(d?) it on" is how I've understood all descriptions of the "rebase" command I've seen. And it's the only way I can make sense of the whole idea -- because otherwise, as you say, it would be the ssame thing as ordinary merges back-and-forth; no need for a separate name for the same thing. (So if you're going to squash the history of your branch down to a single commit anyway, maybe it makes no difference [except possibly for where in the chronological order it goes]? But don't quote me on that either.)