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

321–330 of 404 posts

Re: Git rebase, what can go wrong

#321

Post by oehpr »

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…

A history you can't understand is a history you can't remember.

Re: Git rebase, what can go wrong

#322

Post by sethammons »

dahart wrote: post #42
recursive wrote: post #5

Earlier quoted context omitted.

Squash merges cut down the noise considerably.

What I think I see these days is squash merges being used lazily to avoid having to do anything to build a clean history with clearly semantically delineated commits. Squash merges are good compared to an alternative where people check in super messy noisy branches, but they unfortunately have a big downside because squash merges can make bisecting and history spelunking more difficult, when the branches that are squ…

> they unfortunately have a big downside because squash merges can make bisecting and history spelunking more difficult, when the branches that are squash merged were big

can you help me understand this? It is the exact opposite of my experience. The flow I see is: bug reported, write a git bisect test, identify the feature that introduced it, reach out to that developer/team.

This is allowed by squash merges. When I've seen these more "clean" histories, they have commit points that wont even compile or have runnable tests causing git bisect to fail.

> branches that are squash merged were big

it must be this - how big are your merges? All the projects I've worked on strive for smaller PRs. Large PRs are usually broken up into smaller pieces. Large PRs are an anti-pattern.

Re: Git rebase, what can go wrong

#323

Post by Chris_Newton »

btilly wrote: post #142
lifeisstillgood wrote: post #126

Earlier quoted context omitted.

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?

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

It looks like you’re talking about rewriting history that has already been shared. Pretty much everyone agrees that is a bad idea. It even has a prominent warning in the git book.

What others here, including myself, are advocating is rewriting your own history before you share it, which makes a very different set of trade-offs.

Re: Git rebase, what can go wrong

#324

Post by sethammons »

btilly wrote: post #48
ajkjk wrote: post #12

Earlier quoted context omitted.

Never understood why you wouldn't want it clean. There's no benefit whatsoever to it being messy and it's a liability for a lot of reasons, whereas the clean version is free and easy and makes everything you do that interacts with git history simpler.

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…

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

Re: Git rebase, what can go wrong

#325

Post by sethammons »

alkonaut wrote: post #143

If I were to write a blog post on this I’d make a few do’s and don’ts (why make a blog post when you can blog in HN comments?) Don’t merge the base branch into a feature branch. Rebase to “update”. Do use rerere and the curse of fixing the same conflict over and over is (almost) gone. Don’t rebase (or force push for other reasons) a shared branch. Rule of thumb here is you can probably rewrite history if you work wit…

> Don’t force push after review, until the review is complete. This keeps the history of the review process but you can later merge the fixups with the commits they logically belong in right before merging.

I've had to talk to soooo many developers about this. I want to see what changed since my last review, not restart my review.

Re: Git rebase, what can go wrong

#326

Post by Izkata »

mixmastamyk wrote: post #295
Terr_ wrote: post #272

Earlier quoted context omitted.

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

Comment with a ticket-id would be more efficient.

On a long-lived codebase you're going to end up with nearly as many such comments as there are lines of code. Now that's a cluttered mess.

Re: Git rebase, what can go wrong

#327

Post by js2 »

throw555chip wrote: post #283
js2 wrote: post #205

Earlier quoted context omitted.

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

It's due to GitHub lacking change set support. With Gerrit, force pushing isn't required.

Re: Git rebase, what can go wrong

#328

Post by Izkata »

mixmastamyk wrote: post #303
dkarl wrote: post #136

Earlier quoted context omitted.

It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with a squash merge.

Why not document it then? In a place where everyone can read it, instead of only developers.

...are you suggesting spending hours searching through documentation, hoping to possibly find something relevant, instead of just being able to run "git blame" to see why a specific line was changed?

Re: Git rebase, what can go wrong

#329

Post by thebigspacefuck »

ohwellhere wrote: post #26
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…

The way I phrase and teach what I consider to be the important rule of git is: > Don't rewrite history on shared branches with proper communication. I don't teach "never", I don't teach that `main` is special, I don't teach that force pushing is forbidden, because I don't believe in those things. I highly prefer a rebase-heavy workflow. In addition to not "cluttering" the history, it's an invaluable tool to keep comm…

It’s annoying when someone force pushes to a branch that you just reviewed, but you can no longer see the history so you have to scan through the whole PR you already reviewed looking for the change. Please just commit the fix, let me see it, then squash it.

Re: Git rebase, what can go wrong

#330

Post by Izkata »

nerdponx wrote: post #165
gray_-_wolf wrote: post #76

Earlier quoted context omitted.

You mean like for example `git log --first-parent`?

TIL, thank you! Now I know for a fact that squash-mergers have no excuse and can brandish the man page at them.

People in general just have no idea how much version control is able to do. For one example try running "git help log" and just tap page-down a few (dozen) times to get an idea what's in there.

For another example, you know how people hate aligning code vertically so much that linters don't allow it nowadays, the primary reason being that if you have to change the spacing then the diffs will identify far too many lines as having changed? Both git and svn have options to ignore whitespace changes:

  git diff -w
  svn diff -x -w
Post reply on HN