Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git rebase, what can go wrong

jvns.ca

Post reply on HN
Print view View original

281–290 of 404 posts

Re: Git rebase, what can go wrong

#281

Post by 0xbadcafebee »

The most widely useful method to manage changes in repos is:

  1. Open a new branch and do development there. You can rebase and force-push all you want.
  2. When ready for review, open a PR of the branch, and never rebase again.
  3. On approval, Squash-Merge your PRs and include a merge comment linking to the PR.
This way you can "clean up" your development history in your branch, maintain history of changes requested in a PR, the entire development history is available at the PR link later, and you can revert an entire PR by reverting a single commit.

Re: Git rebase, what can go wrong

#282

Post by drdaeman »

brainzap wrote: post #260

Please write the spec for next generation version control. I feel like Git is great but we could have one which is easier to use and has built in concepts like Pull Prequest or deployed state.

There's a plenty of better*-designed systems, problem is no one (except a few opinionated geeks) cares [enough] so they're unlikely to ever beat Git unless a miracle happens (aka a major industry leader will make something trendy by promoting it).

For example, Darcs (older) and Pijul (newer) are based on patch theory, so Git's rebase issues are moot there.

*) Of course, "better" is subjective.

Re: Git rebase, what can go wrong

#283

Post by throw555chip »

js2 wrote: post #205
diek wrote: post #160

Earlier quoted context omitted.

In general I agree with you, there are absolutely times where you want to retain commit history on a particular branch (although I try to keep the source tree from knowing about things like commit IDs). I would argue that those are by far the minority of PRs that I see. As I mentioned in another comment, _most_ PRs that I see have a ton of intermediary commits that are only useful for that branch/PR/review process (f…

> As I mentioned in another comment, _most_ PRs that I see have a ton of intermediary commits that are only useful for that branch/PR/review process (fixing tests, whitespace, etc). Right, but that's only because developers don't amend and force push their commits to the PR branch as they receive feedback. Which is largely encouraged by GitHub being a terrible code review tool. To me, git is part of the development p…

When the word "force" is involved, it's time to take a step back and re-evaluate things.

Re: Git rebase, what can go wrong

#284

Post by Nullabillity »

foobarbaz33 wrote: post #189
btilly wrote: post #114

Earlier quoted context omitted.

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 th…

> 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 r…

> 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.

The rebase becomes part of the public branch eventually, inflicting your lies on everyone else.

> If you avoid rebase, then you end up "rebasing" without rebasing. You "squash" intermediate states by never recording them to begin with.

If only Git had a third alternative, a way to... entangle two diverging branches of history without destroying or rewriting either. You could say it would be a bit like a car merging into a highway.

> Failing to record history is not superior to squashing it.

"We don't know" is at least an honest statement. Claiming that you do but then making up some nonsense is something that the LLMs do enough of already.

Re: Git rebase, what can go wrong

#286

Post by mostlylurks »

b450 wrote: post #146
duped wrote: post #134

Earlier quoted context omitted.

The point of a clean git history is not to have a clean git history. The point is to make it possible to debug later, via bisect, or show, or even just a diff. The point is to make the workspace clean for the next guy. Instead of letting it go, maybe we should have more discipline and organization in our lives and not less.

Did you notice, though, that rebase advocates use very "emotive" terminology when talking about git history? Like it's a subject they care about? Seems awfully touchy feely.

You say that like it's a bad thing. If there are two groups of people, and one of them is indicating (via words or behavior) that they don't care about something all that much and the other is indicating that they do care about that something quite a bit, why would I ever listen to the ones that don't care? It is almost tautological that the group that actually cares is going to have the more persuasive arguments and is thus far more likely to be right than the apathetic group.

Re: Git rebase, what can go wrong

#287

Post by watwut »

Chris_Newton wrote: post #271
gwright wrote: post #232

Earlier quoted context omitted.

Not my experience, nor my team's experience over almost 10 years of using this approach.

I’m firmly in your camp on this one, but I’ve noticed that advocating a tidy history gets a lot of push-back online. I think there is an element of self-fulfilling prophecy here. If a team habitually leaves a messy history behind, that history is rarely going to be useful, so naturally the team has low expectations and sees little value in doing anything to curate it. And if a team isn’t used to making an effort to c…

I worked in a team where tech lead insisted on nice history. It was a lot of effort all the time and very little to no benefit.

He was lead and could influence salaries, his opinion mattered. So, in real life, people rarely pushed back. That is not the same as us sharing the same opinions tho. I became more verbal about history not being useful online.

Re: Git rebase, what can go wrong

#288

Post by [deleted] »

Lio wrote: post #215
erik_seaberg wrote: post #207

Earlier quoted context omitted.

We shouldn’t tamper with code we don’t actually need to fix, it’s not a good use of time and it makes history less useful. Just because it doesn’t look like I wrote it doesn’t make it wrong.

I’m thinking of situations where the surrounding structure of the code has been changed to correct a problem. That’s done by an automated tool. Correction of indentation is just a byproduct. I don’t consider that “tampering”.

[deleted]

Re: Git rebase, what can go wrong

#289

Post by rhinoceraptor »

naasking wrote: post #71
paulddraper wrote: post #21

Earlier quoted context omitted.

> keeping a clean history This being a principal reason for VCS, I very much understand the motivation.

"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.

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.

Re: Git rebase, what can go wrong

#290

Post by 0x6c6f6c »

throw555chip wrote: post #275
jawns wrote: post #2

I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…

> For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commits cluttering up the commit history. The purpose of history is to remember. Rewriting history, whether git or in life, is bad; outside of the context of don't use it on public repos. Such advice is similar to saying, only point the shotgun away from you when firing. If you have to rememb…

But in unmerged branches, you aren't rewriting history, you're starting your work on a more recent commit in history.
Post reply on HN