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

251–260 of 404 posts

Re: Git rebase, what can go wrong

#251

Post by BeetleB »

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.

As your parent already said, (and it matches my experience), we didn't have any of these problems when using systems without history rewriting (mercurial, for example).

I recall when I first switched to git at work and the team was insisting on a "linear history", I was bemused: Could these developers really not handle a merge graph? It was bizarre how something straightforward in other VCS is suddenly "messy" amongst git folks.

Re: Git rebase, what can go wrong

#252

Post by nilptr »

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.

I use commit history a little bit more than that, but mostly agree. I had another dev recently give me crap about the mess of "WIP" commits on a feature branch because they review by clicking through the commits and my commits don't tell much of a useful story other than I apparently did some shit and eventually it all worked.

That said, I've also come to the conclusion there's basically two classes of Git users: people who really understand Git and use it fully, and those of us who basically use it as a place to shove source code before quitting for the night.

Re: Git rebase, what can go wrong

#253

Post by ajkjk »

BeetleB wrote: post #251
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.

As your parent already said, (and it matches my experience), we didn't have any of these problems when using systems without history rewriting (mercurial, for example). I recall when I first switched to git at work and the team was insisting on a "linear history", I was bemused: Could these developers really not handle a merge graph? It was bizarre how something straightforward in other VCS is suddenly "messy" amongs…

It's not that we/they 'can't' handle it. It's that we choose not to because it's a better life.

It is like moving to one's favorite part of town.

Re: Git rebase, what can go wrong

#254

Post by nojvek »

Squash merge your PRs if using GH. Gives a nice linear history for each piece of work. Keep PRs small and focused to one kind of change.

The PR itself contains full history of subwork. GH can recover branch from PR. No work is lost.

Re: Git rebase, what can go wrong

#255

Post by BeetleB »

ajkjk wrote: post #253
BeetleB wrote: post #251

Earlier quoted context omitted.

As your parent already said, (and it matches my experience), we didn't have any of these problems when using systems without history rewriting (mercurial, for example). I recall when I first switched to git at work and the team was insisting on a "linear history", I was bemused: Could these developers really not handle a merge graph? It was bizarre how something straightforward in other VCS is suddenly "messy" amongs…

It's not that we/they 'can't' handle it. It's that we choose not to because it's a better life. It is like moving to one's favorite part of town.

> It's not that we/they 'can't' handle it. It's that we choose not to because it's a better life.

As someone who has had to put up with rebase for several years now, my life is definitely not better. And things that were trivial in mercurial are now complicated (seeing the actual chronology - both in the log and in the graph). That graph with multiple branches that git developers find messy can actually be really useful.

Re: Git rebase, what can go wrong

#256

Post by nemetroid »

nomel wrote: post #180
nemetroid wrote: post #27

Earlier quoted context omitted.

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…

> * press the "annotate" button in my IDE and can see which commit introduced each line In PyCharm, I can see which commit introduced each line, regardless of branching. Same with drilling down through a files history. Is this an IDE limitation you're seeing? > every step of the way, I get a meaningful description of why Isn't this more about commit messages, than anything else?

The context of my comment is the usefulness of a clean history, not about merging vs rebasing.

> Is this an IDE limitation you're seeing?

I'm using Jetbrains too.

Re: Git rebase, what can go wrong

#257

Post by latexr »

qhwudbebd wrote: post #243
latexr wrote: post #224

Earlier quoted context omitted.

You can shorten `>/dev/null 2>&1` to `&>/dev/null`.

Unfortunately that's bash-specific I think: the POSIX shell spec still hasn't picked it up. (Though strictly speaking, my 'local' is out of spec too.)

Also works in Zsh. Can’t speak for other shells.

Re: Git rebase, what can go wrong

#258

Post by silenced_trope »

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 disagreed with you up to this point:

> Of course if you have developers that don't do that and instead merge dozens of commits that just say wip, wip, wip, lol, fml, wip, wip, lol, yolo and you can't fire them or get them to change, then squash merges ftw.

Yes, any large organization has plenty of devs who all have their own style and preferences, for better or worse.

Whoever demands they all bend to the one true way is a fascist (lol not really but you know).

Just set up your CI/CD in such a way that PRs with weird git logs get squashed into one pretty message, preferably the PR description since other devs have to review the PR it's often given more effort. Set it up so that if things weren't formatted the "right way" they get auto-formatted or a test fails and the dev says "ah, I have to run that one task and then update the PR".

I don't think a big organization is going to scale with developer "evangelists" demanding people write their commits a certain way either.

conventionalcommits.org was the worst. I worked at one "big co" that tried to get devs to do this. Even after we had been doing it for a while, nobody ever went back to look at the history in such a way that it was worth it. We ended up throwing in the towel rather than the company trying to get all other teams to do it.

Re: Git rebase, what can go wrong

#259

Post by orblivion »

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…

This is such a strange thing to say. I'd be curious if you feel the same way about cleaning up your code, or cleaning up your room. I think you have an unfair advantage in this argument because it's difficult to defend such intangible benefits. We have to resort to making up logical explanations, or sounding unhinged or emotional as you suggest.

But it's simply intangible. My instinct tells me that it's helpful and that's okay. I don't owe anyone a justification for how I organize things, and there's nothing controversial about this. (Or maybe I could even come up with a logical example of a benefit, but that's a trap I'm not going to fall into) And a lot of people agree, and they know what I mean, so it's not merely an individual preference. If I have to work with someone who has strong preference against it I'll worry at that point about negotiating.

Post reply on HN