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

211–220 of 404 posts

Re: Git rebase, what can go wrong

#211

Post by erik_seaberg »

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.

When I’m on call and discover at 3 AM that we’re doing something weird, I need to know whether we meant to do that and especially why. In theory you could write all that down, but the people who aren’t doing that in git also won’t do it outside of git. The more you write down, the less likely it is that I need to page you to ask WTF.

Re: Git rebase, what can go wrong

#212

Post by nomel »

jihadjihad wrote: post #60
brunooliv wrote: post #53

Haven't read the article yet. Whenever I'm working on a feature branch, I always tend to "merge master into the feature branch". The effect of this obviously being that I want to have the latest changes incorporated into my work to avoid conflicts and/or to proceed with my own feature work. This has always worked well for me and never failed me. If I understand what rebase does correctly, it just adds all my commits…

Some people don't like having standalone merge commits that show up in the git history when merging master into feature

Why? Is it a visual thing, or practical?

Re: Git rebase, what can go wrong

#213

Post by suzzer99 »

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.

Same, and I've worked on some large, long-running projects. But never at the scale of a big tech company.

I've used git bisect the few times I've had to diagnose an issue that wasn't detected immediately, which gets you down to the exact granular commit.

Re: Git rebase, what can go wrong

#214

Post by nomel »

dahart wrote: post #162
nomel wrote: post #153

Earlier quoted context omitted.

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

> Doesn't this require that pushed code is perfect? We aren’t talking about pushed code. We are talking about cleaning up the local commit history before pushing it into a shared branch.

What about the context where one works with other people, while sharing code?

Re: Git rebase, what can go wrong

#215

Post by Lio »

erik_seaberg wrote: post #207
Lio wrote: post #179

Earlier quoted context omitted.

Git blame confuses people even without squash merges. I've seen people forget to go back more than one commit and then blame the person who last indented a file instead of going back to the commit that actually wrote the code many times.

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

Re: Git rebase, what can go wrong

#216

Post by WorldMaker »

> It also makes me wonder if there’s an easier workflow for cleaning up your commit history that’s harder to accidentally mess up.

Use real merge commits and `--first-parent` as your default view.

It's unfortunate that to make `--first-parent` default you have to either edit your git config or grow a few new habits, and I still think there should be at least few more UIs that are focused on `--first-parent` with optional "drill down" instead of raw subway map diagrams. Subway diagrams look cool in screenshots, but so much of the complaints about "clutter" and "mess" in git seem to be just that people don't actually want to read the subway diagrams.

Re: Git rebase, what can go wrong

#217

Post by latexr »

btilly wrote: post #103
debaserab2 wrote: post #78

Earlier quoted context omitted.

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

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.

Wasn’t `git reflog` viable?

Re: Git rebase, what can go wrong

#218

Post by suzzer99 »

joshribakoff wrote: post #131
ecnahc515 wrote: post #120

Earlier quoted context omitted.

Have you ever had to use git bisect? That's really where a 'clean' git history is important. Plenty of people never use git bisect, and that's fine too. That said it's a very useful tool when you do need it, and can drastically simplify finding when and where a regression was introduced.

You can bisect across the more coarse merge commits, without “destroying” history and losing the ability to bisect across more granular constituent commits. Bisect is more robust when more information is preserved.

This exactly. I'd rather pinpoint the issue to a small commit with only a few changes vs. "well I know which feature caused the issue, now to wade through 65 changed files."

Re: Git rebase, what can go wrong

#219

Post by suzzer99 »

htamas wrote: post #181
AndrewDucker wrote: post #70

I find it fascinating that people talk about "Having a history of what people did" in such emotive terms - "Cluttering", "Polluting". 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 o…

A clean git history on a pull request also makes it easier for the reviewer to understand your code. Small, concise commits will tell the reviewers about your train of thought or what issues did you run into, making it easier to pick up the context. I start with every code review by looking at the commit history. I prefer not to have squash commits in our team for this reason. It makes master look good, but usually n…

Yeah we use pull requests for the coarse-grained stuff and leave the small commits, which should also have good comments, intact. Maybe other shops use pull requests differently.

Re: Git rebase, what can go wrong

#220

Post by WorldMaker »

bonzini wrote: post #206
toast0 wrote: post #201

Earlier quoted context omitted.

> * enables use of git bisect to locate bugs This is really only viable if each intermediate commit on a development branch is intended to be bug free. If that's the standard you and your team work with, that's fine, but it's not usually my standard; in a development branch, I may commit things that don't even compile, let alone work, if it's a good point to commit.

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.

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.
Post reply on HN