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

301–310 of 404 posts

Re: Git rebase, what can go wrong

#301

Post by sangnoir »

gwright wrote: post #190
bogeholm wrote: post #108

Earlier quoted context omitted.

I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.

> why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Several reasons: * facilitates much better code review discussions * enables use of git bisect to locate bugs * allows for informative commit messages associated with the changes * communicates clearly to future self about why changes were made

There are a multitude of Git workflows, and opinions on what the basic unit of change is: for some, a feature is atomic, so squash-merging feature branches is perfectly natural.

> facilitates much better code review discussions

This can be done while adding code to the feature branch

> allows for informative commit messages associated with the changes

I'm assuming you consider individual commits to be the basic unit of change? This isn't always the case. Some products are not amenable to adding features fractionally

> communicates clearly to future self about why changes were made

You can do that with a squash-merge too!

I've noticed people who work on an evergreen deployment can afford to work on a very granular, commit-level. However, if you have to support multiple production branches concurrently and often have to cherry-pick features and fixes across them, features will naturally become the basic unit of change you will find yourself gravitating towards, and will liberally use squash-merging just to keep your sanity.

Re: Git rebase, what can go wrong

#303

Post by mixmastamyk »

dkarl wrote: post #136
jimbob45 wrote: post #112

Earlier quoted context omitted.

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. This is too much thought put into a VCS. I don’t want to have to think about my VCS at all beyond the commit message. For all of Git’s popularity, I’ve never seen benefits that justify the absurd amount of work and knowledge it takes t…

It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with a squash merge.

Why not document it then? In a place where everyone can read it, instead of only developers.

Re: Git rebase, what can go wrong

#304

Post by conaclos »

ajkjk wrote: post #8

I love rebase (I'm a tip-of-master-only person, no merges ever, squash all your commits with `rebase -i` before pushing and write one good commit message for the group). But there's one really, really irritating thing about them: You should not be able to use `--amend` during a rebase. For me editing all my changes onto the commit I'm working on with `git commit -a --amend` (or as I've aliased it, `gcaa`) is automati…

I also encounter this issue. I would also like to forbid amendind a commit that is not part of the working branch.

Re: Git rebase, what can go wrong

#305

Post by yxhuvud »

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.

But that make no sense, as the second someone pulls from that branch it would be noticed.

Re: Git rebase, what can go wrong

#306

Post by m000 »

mixmastamyk wrote: post #298
m000 wrote: post #280

Earlier quoted context omitted.

Curating the commit history takes like 10' per PR and can easily repay in hours of work when some bug hits. Or when you want to tell the junior that wants to implement X for A, why don't you take a look on this one commit where we implement X for B?

Is there something wrong with the latest version of the method? Instead of one from ~18 months ago which may not work any longer?

I'm not sure I get you. What do you mean the "latest version of the method"? And why shouldn't code from 18 months ago not work? Some minimal regression testing should be in place for production code, and it is probably also used regularly.

So, yes seeing e.g. how "CSV export for class A" is implemented is a great guide for implementing "CSV export for class B".

Re: Git rebase, what can go wrong

#307

Post by Rapzid »

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…

There is a reason so many open source projects require squashing.

Ain't nobody got time for that shit.

Re: Git rebase, what can go wrong

#308

Post by leptons »

jawns wrote: post #2

I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…

I don't mind merge commits, it's the 100 tiny individual commits some developers seem to like to do that really clutters things up. Yes, I know, git squash is a thing, but not committing until the feature is working and ready to commit is also a thing.

Re: Git rebase, what can go wrong

#309

Post by Chris_Newton »

mixmastamyk wrote: post #293
Chris_Newton wrote: post #271

Earlier quoted context omitted.

I’m firmly in your camp on this one, but I’ve noticed that advocating a tidy history gets a lot of push-back online. I think there is an element of self-fulfilling prophecy here. If a team habitually leaves a messy history behind, that history is rarely going to be useful, so naturally the team has low expectations and sees little value in doing anything to curate it. And if a team isn’t used to making an effort to c…

If a strategy requires humans to be virtuous AND vigilant it is doomed to failure. I rarely use history and prefer merge/squash, with automated CI tools, and tests. "Why" is kept in doc strings, comments, specs, and story tickets. Everything viewable in gitlab with automatic links. All this gets out of the critical path, every day. I submit that, if your code is so complex that diagnosing a bug is a major research pr…

If a strategy requires humans to be virtuous AND vigilant it is doomed to failure.

Sorry, but I don’t buy that. By the same principle, there’s also no point in writing unit tests or defining static types or having code reviews, all of which require thought and extra work, yet can yield considerable dividends when done even moderately well.

I rarely use history and prefer merge/squash, with automated CI tools, and tests. "Why" is kept in doc strings, comments, specs, and story tickets.

The argument for a tidy history isn’t just about a different place to explain a change. It’s about presenting work in clearly defined, meaningful steps to other readers like code reviewers, or perhaps someone who found these commits later through `git blame` on a problematic line of code or `git bisect` after a regression. It’s about each commit representing a complete, self-contained change that could later be reverted, or cherry-picked or merged to another branch.

I submit that, if your code is so complex that diagnosing a bug is a major research project rather than moving forward with a few extra/modified lines of obvious fix, then that is the problem to focus on.

Some problems have a lot of essential complexity. The code to solve them necessarily has at least the same degree of complexity. Sooner or later, there will probably be a change to that code with an unintended consequence for something else. Keeping the code and its history tidy and systematic is, IMHO, how you avoid those investigations becoming major research projects.

Post reply on HN