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

151–160 of 404 posts

Re: Git rebase, what can go wrong

#151

Post by lifeisstillgood »

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…

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.

Re: Git rebase, what can go wrong

#152

Post by js2 »

The trick to using `rerere` with `rebase` is to merge first, resolve the conflict, record the resolution, then go back and do the rebase. It's explained here:

https://www.git-scm.com/book/en/v2/Git-Tools-Rerere

It's often easier to resolve a conflict during a merge than during a rebase because it presents you with left, right, and the common ancestor. You're also only looking at the tips of each branch. With rebasing, you're replaying each commit one on top of the next so you lose the common ancestor information and you may also have conflicts that won't exist at the end.

Another tip: if the other branch has changed a lot since you last rebased, even a single merge may have a lot more conflicts than you want to deal with all at once. In this case, consider a series of intermediate merges since you're going to throw them all away anyway.

Re: Git rebase, what can go wrong

#153

Post by nomel »

ruds wrote: post #111
sidlls wrote: post #107

Earlier quoted context omitted.

Perhaps I'm missing something, but I don't see how your comment answers my questions. Do you mean that a "clean history" is one without "fix 1", "fix 2" and "fix 3"? Or is that a "semantically delineated commit"?

A clean history is one where there is a single commit, "big feature commit", that produces a worktree that is the same as the one produced by "fix 3" in the "unclean" history.

How is this possible, while sharing code? Doesn't this require that pushed code is perfect? What about everyone else working on the same code? Do they wait until you've reached perfection? Or, do you squash the branch once it's complete, with the assumption that there's no other development on/from that temporary branch (I envy you if so)?

(I ask these questions fully assuming I'm doing it wrong.)

Re: Git rebase, what can go wrong

#154

Post by gabeio »

git --force needs to just be an alias of force-with-lease by default. having the default be the unsafer option seems... backwards. It should be something more like:

    git --force (acts like git --force-with-lease does now)
    git --force-anyway (acts like --force does now, "anyway" is just an example and should be harder/longer than -f/--force)
I understand that force-with-lease didn't exist first but this needs to be rectified.

Re: Git rebase, what can go wrong

#155

Post by awkward »

I've largely come to a workflow of creating a feature branch and periodically merging main out to that branch. When it's done, I use the github squash and merge feature to bring changes back in. Cutting non-ancestor rebases out of my workflow has been great for my personal sanity.

Re: Git rebase, what can go wrong

#156

Post by phendrenad2 »

I'm jealous of people who enjoy rebasing. Such a simple life they must lead. When I'm tasked with rebasing a feature branch with 1,000 commits, written by 10 different people, onto a new release branch with another 1,000 new unrelated commits, written by 10 different people, I really start to question my life choices.

Re: Git rebase, what can go wrong

#157

Post by sidlls »

smw wrote: post #129
sidlls wrote: post #54

Earlier quoted context omitted.

What is a "semantically delineated commit"? What is a "clean history"? Why are these two things important?

A bunch of wip wip2 wip3 commits don't add any value, and make the log harder to read. But if you break a bigger PR down into "added feature x", "tests for feature x", "refactored y to support x" -- the commits are easier to read and provide valuable "why" history when you're trying to figure out what happened two years later.

That's more about the contents of the merged commits than anything else. Modifying the commit message(s) fixes that, as long as that's what the commits actually did.

Aside from that, how are "a fix for a bug" style commits not "clean"? If merge 123 into master contains a bug that is fixed in a future merge 1234, it doesn't seem "dirty" to me; quite the opposite actually, as it tracks what actually happened.

Now, "wip" style commits shouldn't be on whatever main branch everyone is working on: that's what branches are for. And if everyone is just working off the main branch and committing directly to it, that's an organizational deficiency; not one that VCS can solve.

Re: Git rebase, what can go wrong

#159

Post by nomel »

jjeaff wrote: post #117
FeepingCreature wrote: post #90

Earlier quoted context omitted.

> What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot of time doing git-bisect. And git blame. And git checkout to a past state. It "doesn't matter" only if ease of understanding your pro…

how often is "understanding your project history" something that actually comes up for you? In all my years of working with projects in git, I will occasionally look at my history to help me find a change that may have led to a bug, but it really only comes up for me once or twice a year and even then, it is rarely an extensive deep dive and never very far back in time.

> I will occasionally look at my history

It's others history that I'm usually interested in. I can easy follow the small diffs of individual commits, but have a much harder time grokking a wall of red and green.

Re: Git rebase, what can go wrong

#160

Post by diek »

js2 wrote: post #128
diek wrote: post #56

Earlier quoted context omitted.

> I die a little bit each time I try to understand what changes were related to a line when tracking down a bug A change/feature/bug is a branch, which is squashed into a commit on your main branch, right? So your main branch should be a linear history of changes, one change per commit. How does that impact the ability to git blame?

Because unless it's the most trivial of features, you'll break it up into smaller commits which each explain what they are doing and make reviewing the change easier. As a simple example, I recently needed to update a json document that was a list of objects. I needed to add a new key/value to each object. The document had been hand edited over the years and had never been auto-formatted. My PR ended up being three c…

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 (fixing tests, whitespace, etc). Generally the advice I give teams is, "squash by default" and then figure out where the exceptions to that rule are. That's mainly because, in my opinion, the downsides of a noisy commit graph filled with "addressing review comments" (or whatever) commits are a much bigger/frequent issue than the benefits you talk about. It really depends on the team.

Post reply on HN