4 ms·

There is a giant benefit to it being messy. And that is that the mess is the actual history. Every time you do a git rebase, you are literally asking your sour

by btilly 3y ago

There is a giant benefit to it being messy. And that is that the mess is the actual history. Every time you do a git rebase, you are literally asking your source control system to lie about history. If you mess up, and you eventually will, you're then forced to manually figure out what the history really was despite being lied to. If you mess it up, well, good luck. I used to work at a company where someone (we never figured out who) in another group would rebase every few weeks. We didn't find out about it until their stuff was pushed then released. The result was that features which we'd written, QAed, and released to production would simply disappear a few weeks later. With no history suggesting that it ever existed. Have you ever been pulled off of a project to go fix a project from a month ago which has disappeared from source control? You don't know what happened, you no longer have context, you've just got complaints because your stuff no longer works. Is your desire for a "clean history" worth potentially creating THAT disaster for other developers on your team???

diek 3y ago
The golden rule is "do not rewrite history of a public branch". Rebase/squash your PR branches to your heart's content, but once it's merged that's it. You get clean history by not merging branches with 50 intermediary "fiddling with X" commits in them.
- btilly 3y ago
  Related, it is a bad idea to use long-running per team branches. Merge early, merge often, get commits to trunk ASAP. With best practices on unit testing, code review, and so on, this scales to many thousands of developers. And will save a lot of pain over time.
debaserab2 3y ago
> I used to work at a company where someone (we never figured out who) Wouldn't this be trivially solvable by git bisecting your deploy branch?
- btilly 3y ago
  No, because git bisect operates off of the information in the history. And thanks to the bad rebase, the history no longer existed in the branch.
  - deleted 3y ago
    [deleted]
  - lifeisstillgood 3y ago
    Just clarifying ... they took a version of master from say a month ago, did their work on it, then, they force pushed their work out, wiping everyone else's work that was added to master since one month ago? I mean that's the equivalent of reversing your JCB through a house on a building site because "the house was not there a week ago when I last moved the JCB". or am I missing something?
    - btilly 3y ago
      Basically equivalent to that. This was about a decade ago. We had 4 teams, each released on a schedule. Each team had a branch. When a team released, it was merged from master, then each team pulled. The person who did the pull would change, and it was often a rebase. So my team released, some other team rebased badly. There would be no sign of problems for us until after they released. But since 2 teams generally released at once, and people didn't remember who actually did the merge a few weeks earlier, it was hard to figure out who was actually messing up. (I had suspicions, but no proof.) I've seen rebase used appropriately since. But that disaster left scar tissue.
      - lifeisstillgood 3y ago
        So (sorry for picking on this scab) there became 4 branches each of which for the team concerned was the next beautiful branch and then say each week a team woukd merge into master and everyone woukd rebase but fuck that up once and now the beautiful branch team B is working on is out of step with the real master ... oh god. Yeah that would leave a mark.
foobarbaz33 3y ago
> the mess is the actual history. The true history is not recorded in your normal commits either. Every time you modify your source buffer, that is the true sequence of events. This truth is lost already as you undo/rework things before you commit. You're ALWAYS manipulating and telling a false story of history whether you realize it or not. Commits are a tool that give stronger backup/undo protections over simple file saves and in-memory editor undo lists. Just because you happened to save your work in a commit doesn't mean it should be instantly be regarded as holy history. Not anymore so than if you simply saved the file. I think the bar for "holy" history should be whether it is published to a shared branch.
- btilly 3y ago
  I believe that you are confusing "full history" and "true history". Every single point in the commit history represents an actual state of a repository at a specific point of time, along with the information of which point or points were next before it. This is all part of the true history. This is not a full history - you don't have every keystroke, abandoned commit, switch between branches and so on. But nothing that you're being told is wrong. As soon as you do a rebase, you're rewriting history. You're claiming that there were specific points of time with specific states that never actually existed. You're losing information about points of time and specific states that actually existed, which someone once considered important enough to do a git commit over. The difference becomes important if that someone, which at a previous job was me far more often than I would like, tries to go back to the historical commit. And finds that it is gone without a trace.
  - foobarbaz33 3y ago
    > As soon as you do a rebase, you're rewriting history. Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch. > You're losing information about points of time and specific states that actually existed If you avoid rebase, then you end up "rebasing" without rebasing. You "squash" intermediate states by never recording them to begin with. Failing to record history is not superior to squashing it. > And finds that it is gone without a trace. I don't have the details, but it sounds like someone rebased a public branch. Yes that is bad. But it's sort of like saying we shouldn't drive cars because someone chose to drive the wrong direction down a 1 way road.
Arch-TK 3y ago
If you think the mess (i.e. 50 mixed up mini commits as you work on a feature and iterate on it) is useful history (it usually isn't) then use a different DVCS because git was not designed around this mode of operation and a lot of its advanced features work poorly when applied to such a history. Alternative DVCSes which support this workflow include: fossil
ajkjk 3y ago
IMO the relevant 'true history' is at the plane of 'things relevant to other developers'. As far as anyone is concerned, my local work history is that I atomically wrote all my code in a single instant. Commits are that unit of atomicity. But I have never seen a commit disappear while rebasing, ever. That workflow is busted somehow. They were doing it wrong.
dkbrk 3y ago
> the mess is the actual history. This argument reminds me of a scene from Yes Prime Minister [0]: > Humphrey: The minutes do not record everything that was said at a meeting do they? > Bernard: Well of course not. > Humphrey: And people change their minds during a meeting don't they? > Bernard: Well, yes. > Humphrey: The actual meeting is a mass of ingredients for you to choose from. > Bernard: Oh, like cooking? > Humphrey: No, not like cooking. Better not to use that word in connection with books or minutes. You choose, from a jumble of ill-digested ideas, a version which represents the Prime Minister's views, as he would, on reflection, have liked them to emerge. > Bernard: But if it's not a true record... > Humphrey: The purpose of minutes is not to record events it is to protect people. You do not take notes if the Prime Minister say something he did not mean to say, particularly if it contradicts something he has said publicly. You try to improve on what has been said, to put it in a better order. You are tactful. > Bernard: But how do I justify that? > Humphrey: You are his servant > Bernard: Oh, yes. > Humphrey: A minute is a note for the records and a statement of action if any that was agreed upon. I think the analogy is pretty clear. A pull request does not record every single little change you made when writing it. You choose, from a jumble of ill-digested ideas, a version which better reflects your intent as you would, on reflection, have liked it to emerge. It doesn't matter that it's not a true record, since its purpose is not to record events but to communicate ideas. You try to improve on the commits as they have been written, to put it in a better order. You are tactful. [0]: https://youtu.be/MF-Qnv2Srfs?si=U6xKNLrTAIn5h1Iz&t=118 https://youtu.be/MF-Qnv2Srfs?si=U6xKNLrTAIn5h1Iz&t=118
- Nullabillity 3y ago
  You do realize that Yes, Minister is satire...?
sethammons 3y ago
this exact problem led us to block all --force pushes.
- ajkjk 3y ago
  Yeah, that's a standard feature in large organizations afaik.

by btilly 3y ago

diek 3y ago

The golden rule is "do not rewrite history of a public branch". Rebase/squash your PR branches to your heart's content, but once it's merged that's it. You get clean history by not merging branches with 50 intermediary "fiddling with X" commits in them.

btilly 3y ago
Related, it is a bad idea to use long-running per team branches. Merge early, merge often, get commits to trunk ASAP. With best practices on unit testing, code review, and so on, this scales to many thousands of developers. And will save a lot of pain over time.

debaserab2 3y ago

> I used to work at a company where someone (we never figured out who) Wouldn't this be trivially solvable by git bisecting your deploy branch?

btilly 3y ago
No, because git bisect operates off of the information in the history. And thanks to the bad rebase, the history no longer existed in the branch.
- deleted 3y ago
  [deleted]
- lifeisstillgood 3y ago
  Just clarifying ... they took a version of master from say a month ago, did their work on it, then, they force pushed their work out, wiping everyone else's work that was added to master since one month ago? I mean that's the equivalent of reversing your JCB through a house on a building site because "the house was not there a week ago when I last moved the JCB". or am I missing something?
  - btilly 3y ago
    Basically equivalent to that. This was about a decade ago. We had 4 teams, each released on a schedule. Each team had a branch. When a team released, it was merged from master, then each team pulled. The person who did the pull would change, and it was often a rebase. So my team released, some other team rebased badly. There would be no sign of problems for us until after they released. But since 2 teams generally released at once, and people didn't remember who actually did the merge a few weeks earlier, it was hard to figure out who was actually messing up. (I had suspicions, but no proof.) I've seen rebase used appropriately since. But that disaster left scar tissue.
    - lifeisstillgood 3y ago
      So (sorry for picking on this scab) there became 4 branches each of which for the team concerned was the next beautiful branch and then say each week a team woukd merge into master and everyone woukd rebase but fuck that up once and now the beautiful branch team B is working on is out of step with the real master ... oh god. Yeah that would leave a mark.

foobarbaz33 3y ago

> the mess is the actual history. The true history is not recorded in your normal commits either. Every time you modify your source buffer, that is the true sequence of events. This truth is lost already as you undo/rework things before you commit. You're ALWAYS manipulating and telling a false story of history whether you realize it or not. Commits are a tool that give stronger backup/undo protections over simple file saves and in-memory editor undo lists. Just because you happened to save your work in a commit doesn't mean it should be instantly be regarded as holy history. Not anymore so than if you simply saved the file. I think the bar for "holy" history should be whether it is published to a shared branch.

btilly 3y ago
I believe that you are confusing "full history" and "true history". Every single point in the commit history represents an actual state of a repository at a specific point of time, along with the information of which point or points were next before it. This is all part of the true history. This is not a full history - you don't have every keystroke, abandoned commit, switch between branches and so on. But nothing that you're being told is wrong. As soon as you do a rebase, you're rewriting history. You're claiming that there were specific points of time with specific states that never actually existed. You're losing information about points of time and specific states that actually existed, which someone once considered important enough to do a git commit over. The difference becomes important if that someone, which at a previous job was me far more often than I would like, tries to go back to the historical commit. And finds that it is gone without a trace.
- foobarbaz33 3y ago
  > As soon as you do a rebase, you're rewriting history. Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch. > You're losing information about points of time and specific states that actually existed If you avoid rebase, then you end up "rebasing" without rebasing. You "squash" intermediate states by never recording them to begin with. Failing to record history is not superior to squashing it. > And finds that it is gone without a trace. I don't have the details, but it sounds like someone rebased a public branch. Yes that is bad. But it's sort of like saying we shouldn't drive cars because someone chose to drive the wrong direction down a 1 way road.

Arch-TK 3y ago

If you think the mess (i.e. 50 mixed up mini commits as you work on a feature and iterate on it) is useful history (it usually isn't) then use a different DVCS because git was not designed around this mode of operation and a lot of its advanced features work poorly when applied to such a history. Alternative DVCSes which support this workflow include: fossil

ajkjk 3y ago

IMO the relevant 'true history' is at the plane of 'things relevant to other developers'. As far as anyone is concerned, my local work history is that I atomically wrote all my code in a single instant. Commits are that unit of atomicity. But I have never seen a commit disappear while rebasing, ever. That workflow is busted somehow. They were doing it wrong.

dkbrk 3y ago

> the mess is the actual history. This argument reminds me of a scene from Yes Prime Minister [0]: > Humphrey: The minutes do not record everything that was said at a meeting do they? > Bernard: Well of course not. > Humphrey: And people change their minds during a meeting don't they? > Bernard: Well, yes. > Humphrey: The actual meeting is a mass of ingredients for you to choose from. > Bernard: Oh, like cooking? > Humphrey: No, not like cooking. Better not to use that word in connection with books or minutes. You choose, from a jumble of ill-digested ideas, a version which represents the Prime Minister's views, as he would, on reflection, have liked them to emerge. > Bernard: But if it's not a true record... > Humphrey: The purpose of minutes is not to record events it is to protect people. You do not take notes if the Prime Minister say something he did not mean to say, particularly if it contradicts something he has said publicly. You try to improve on what has been said, to put it in a better order. You are tactful. > Bernard: But how do I justify that? > Humphrey: You are his servant > Bernard: Oh, yes. > Humphrey: A minute is a note for the records and a statement of action if any that was agreed upon. I think the analogy is pretty clear. A pull request does not record every single little change you made when writing it. You choose, from a jumble of ill-digested ideas, a version which better reflects your intent as you would, on reflection, have liked it to emerge. It doesn't matter that it's not a true record, since its purpose is not to record events but to communicate ideas. You try to improve on the commits as they have been written, to put it in a better order. You are tactful. [0]: https://youtu.be/MF-Qnv2Srfs?si=U6xKNLrTAIn5h1Iz&t=118 https://youtu.be/MF-Qnv2Srfs?si=U6xKNLrTAIn5h1Iz&t=118

Nullabillity 3y ago
You do realize that Yes, Minister is satire...?

sethammons 3y ago

this exact problem led us to block all --force pushes.

ajkjk 3y ago
Yeah, that's a standard feature in large organizations afaik.