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

231–240 of 404 posts

Re: Git rebase, what can go wrong

#231

Post by WorldMaker »

PaulDavisThe1st wrote: post #193
Lio wrote: post #170

> fixing the same conflict repeatedly is annoying This is usually caused by merging an upstream branch (e.g. develop) into your feature branch and then later trying rebase it. Effectively the commits you've merged in from develop undo the changes you've made in your feature branch. You fix them but the foreign commits undo the changes again. The solution is actually pretty easy. Use git rebase --interactive to remove…

> The solution is actually pretty easy. git rerere is the even easier solution.

I've had to force people to clear their git rerere caches as debugging the situation when that cache is FUBAR is gross.

Re: Git rebase, what can go wrong

#232

Post by gwright »

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.

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

Re: Git rebase, what can go wrong

#233

Post by hhjinks »

erik_seaberg wrote: post #203
joshribakoff wrote: post #123

Earlier quoted context omitted.

You can simply ask “git log” to show you one coarse entry per Pr rather than “destroying” the more granular history

This. It bugs me that people permanently throw away details of changes rather than show just the log of merge commits.

Why would I want to keep the details? Umpteen "tmp", "fix" and "fixed typo" provide negative value. When I check the blame of a line, I need to see the context of the change, meaning a description of all the work that was done as part of that change, and perhaps a ticket number. Anything else is noise that actively detracts from the value of the log.

It's like 4K porn. It's less appealing when you see everything.

Re: Git rebase, what can go wrong

#235

Post by hhjinks »

nomel wrote: post #214
dahart wrote: post #162

Earlier quoted context omitted.

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

You fix your local tree before sharing it. Alternatively, you can communicate with your team and tell them they'll need to run git fetch && git rebase -i origin/main to drop your erroneously merged commits.

Re: Git rebase, what can go wrong

#236

Post by WorldMaker »

nemetroid wrote: post #27
davedx wrote: post #9

I’ve never understood the tradeoff of rebasing, squashing or otherwise “keeping a clean history”. It always seemed like tons of sometimes highly error prone work (sometimes you can wipe out a colleague’s work with it! Wtf!), for almost no gain (why does it matter that the git history is “clean”?).

It matters because when I: * use filtering commands like "git log -S" * press the "annotate" button in my IDE and can see which commit introduced each line * run "git bisect" * use "tig" to drill down through the history of a file (shortcut "," is "move to commit preceding current line's blame commit") ...every step of the way, I get a meaningful description of why a change was made and what other diffs were necessar…

* `git log --first-parent -S`

* `git blame --first-parent`

* `git bisect --first-parent`

* At least one "tig-like" with a --first-parent first UI: https://github.com/kalkin/git-log-viewer

Re: Git rebase, what can go wrong

#237

Post by LAC-Tech »

ajkjk wrote: post #12
davedx wrote: post #9

I’ve never understood the tradeoff of rebasing, squashing or otherwise “keeping a clean history”. It always seemed like tons of sometimes highly error prone work (sometimes you can wipe out a colleague’s work with it! Wtf!), for almost no gain (why does it matter that the git history is “clean”?).

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.

I want it clean. But I don't want to do the work to make it clean. The juice is not worth the squeeze.

Re: Git rebase, what can go wrong

#238

Post by WorldMaker »

js2 wrote: post #152

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…

It's all fun and games until someone's rerere cache is spitting out spurious bug regressions that make little sense.

Re: Git rebase, what can go wrong

#239

Post by jdhzzz »

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…

That was me.

Got fired. Kinda. I was laid off.

Re: Git rebase, what can go wrong

#240

Post by pjc50 »

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.

Sometimes. Once every few months. Sometimes it conveys useful information. Sometimes it just hits the "product imported from previous VCS a decade ago" commit.
Post reply on HN