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

271–280 of 404 posts

Re: Git rebase, what can go wrong

#271

Post by Chris_Newton »

gwright wrote: post #232
watwut wrote: post #225

Earlier quoted context omitted.

Frankly, people lately spend more time managing commit history then using it. Like, commit history is useful once in a year little bit, maybe, but we spend absurd amount of time trying to make it look nice.

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 curate its history, they may assume that doing so is expensive because `git rebase -i` is scary and not something they use on auto-pilot for a few seconds at a time.

In other news, our developers also create several small PRs every day but each is for an incomplete change that doesn’t stand alone so we’re never quite sure which features are finished in any given build, everyone keeps complaining about being interrupted to do code reviews all the time when the code reviews have no value anyway because they always just say LGTM :+1:, and we have targets that no more than 15% of commits should break production when CI/CD deploys them and that we recover fully within an hour each time that happens. If only there were something we could do to improve all this…

Re: Git rebase, what can go wrong

#272

Post by Terr_ »

watwut wrote: post #225
bonzini wrote: post #206

Earlier quoted context omitted.

The point of the parent comment is exactly that you should clean up the history before merging to a public branch, so that you can use bisect, even if so far you had wip wip doh wip as the commit messages. The way to get there is to have a mix of proper and wip commits.

Frankly, people lately spend more time managing commit history then using it. Like, commit history is useful once in a year little bit, maybe, but we spend absurd amount of time trying to make it look nice.

> Frankly, people lately spend more time managing commit history then using it.

At one company with a Giant Custom Enterprise App, I ended up occasionally acting as a historian for pieces of the company with bad communication/institutional-memory, ex: "Oh, the +5% Foo charge was because of a request 3 years ago by vice-president X, here's the ticket number, before that it used to be +3%."

In those circumstances--where the implementation is the source of truth for business process--a well-maintained stream of commit-messages become quite useful.

Re: Git rebase, what can go wrong

#273

Post by m000 »

bogeholm wrote: post #108
dkarl wrote: post #92

Earlier quoted context omitted.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…

I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.

> I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later.

Squash-merge is a scourge. I've seen squash merged commits 30 lines long ("try 15", empty line, "try 14", empty line...). I'm not even sure if you can do anything about such commits because squash-merge is a github/gitlab thing. So, I'm not sure if there are hooks to block it via a commit message linter.

And I've seen people going through some intense mental gymnastics to justify avoiding squashing locally, writing a proper commit message and then merging.

Re: Git rebase, what can go wrong

#274

Post by WorldMaker »

bonzini wrote: post #246
WorldMaker wrote: post #220

Earlier quoted context omitted.

If merge points are your "known good" points anyway you can just use the powers of the git dag and `git bisect --first-parent` in your main branch to just bisect the merge points. There's no need for rebase/squash and you still get useful git bisect results.

All commits are good points and potentially useful points. Was the bug in the refactoring? In the feature itself? In the resolution of merge conflicts? You can only answer if you don't squash, and it becomes easier to fix the bug if you know the answer.

Sure, but also no one particularly wants to CI every commit inside a PR, so there is a usefulness in `git bisect --first-parent` as the "first pass" of known CI points (merge commits presumably from PRs) to find the "PR that introduced the problem" and then drill down into every smaller commit to see if you can get additional bisect information (from commits that may or may not have passed CI in the first place in development work-in-progress).

Re: Git rebase, what can go wrong

#275

Post by throw555chip »

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 remember such a rule, it's best to avoid it.

Re: Git rebase, what can go wrong

#276

Post by throw555chip »

bogeholm wrote: post #108
dkarl wrote: post #92

Earlier quoted context omitted.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…

I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.

> why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later.

Agreed, it has been standard at most shops I've worked in the past 8-10 years.

Re: Git rebase, what can go wrong

#277

Post by Nullabillity »

dkbrk wrote: post #262
btilly wrote: post #48

Earlier quoted context omitted.

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…

> 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? > H…

You do realize that Yes, Minister is satire...?

Re: Git rebase, what can go wrong

#278

Post by zaptheimpaler »

dkarl wrote: post #92
recursive wrote: post #5

Earlier quoted context omitted.

Squash merges cut down the noise considerably.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…

I get why you would prefer it clean but its just too much overhead for me. I naturally make lots of changes together - especially on a complex feature, you need to build things in a "full-stack" way horizontally so you can test as you go. Then pulling things apart into "clean" atomic commits later just takes too much time and I don't really know how to do it efficiently.

Re: Git rebase, what can go wrong

#279

Post by watwut »

orblivion wrote: post #270
watwut wrote: post #264

Earlier quoted context omitted.

> I'd be curious if you feel the same way about cleaning up your code, or cleaning up your room Very genuinely: I do not care at all whether you clean your room starting from left and continuing to right. Or, starting from doors and continuing toward window. Or whether you clean it in a random order. I also do not care about whether you clean every Friday or whenever you feel like. That is the equivalent of git histo…

> I do not care at all whether you clean your room starting from left and continuing to right But you didn't say that you don't want it clean. It sounds like you're talking about how it's organized rather than whether it's organized. > The reason why it is hard to defend I'm talking about intangible benefits and no that's not the reason. Intangible benefits are inherently difficult to defend in words. Citing this as…

Insisting on highly organized git history is like insisting on particular order of cleaning. History is not the product itself. It is not the code itself. It is less important and matters only a little.

In the rare situation when I have to read it, I am perfectly ok looking at previous commit too or whatever. It is still less overall work then what people describe in here.

Even with room, I do not want my room infinitely clean. I am ok when books are not ordered by height and color for example. I do not need t-shirst ordered by color either.

Re: Git rebase, what can go wrong

#280

Post by m000 »

watwut wrote: post #225
bonzini wrote: post #206

Earlier quoted context omitted.

The point of the parent comment is exactly that you should clean up the history before merging to a public branch, so that you can use bisect, even if so far you had wip wip doh wip as the commit messages. The way to get there is to have a mix of proper and wip commits.

Frankly, people lately spend more time managing commit history then using it. Like, commit history is useful once in a year little bit, maybe, but we spend absurd amount of time trying to make it look nice.

Curating the commit history takes like 10' per PR and can easily repay in hours of work when some bug hits. Or when you want to tell the junior that wants to implement X for A, why don't you take a look on this one commit where we implement X for B?
Post reply on HN