Hacker News new | ask | show | jobs
by tornadofart 639 days ago
Git rebase aka People rewriting history to make it LOOK like the commit was a compilable, working work result at a point in time even though the real history was something completely different, then f*cking up the rewriting of said history, then whining "please mighty Senior SWE heeeelp I don't know what happened please help my work is gone".

It all has trade-offs.I prefer seeing the dirty laundry.

2 comments

I don't; once the feature has been merged, how you got to that point is no longer relevant; it's noise. Git is a log of code changes, if you use it as a work log you're using it wrong.
I don't think you're wrong. I think we have different priorities.

And we obviously have different expectations of what should happen if the code of a certain commit is run.

That the code is “compilable, runnable” is never a given even if you never use rebase.

We can sling around stereotypes of people failing and doing a bad job with their strategy. Then going to cry to someone (presumably you?). But I don’t think that advances the conversation.

True. And I don't think I ever claimed that never using rebase is a guarantee for anything.

I rather wanted to point out the following: Using a commit strategy based on git rebase is neither right nor wrong. It is not even best practice IMO. It has its own footguns.

Since the parent comment was very opinionated and cast judgement, I responded in kind.

I have been the person crying as well as the one who solved the mess, let's not kid ourselves.

> Since the parent comment was very opinionated and cast judgement, I responded in kind.

Fair. :)