Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git Rebase for the Terrified

brethorsting.com

Post reply on HN
Print view View original

201–210 of 305 posts

Re: Git Rebase for the Terrified

#201

Post by doctorpangloss »

bluGill wrote: post #168
skipkey wrote: post #84

Earlier quoted context omitted.

I can give you an example of when I am glad I rebased. There have been many times I have been working on a feature that was going to take some time to finish. In that case my general workflow is to rebase against main every day or two. It lets me keep track of changes and handle conflicts early and makes the eventual merge much simpler. As for debugging I’ve never personally had to do this, but I imagine git bisect w…

I used hg (mercurial) before git. Every time I see someone make an argument like yours I think "only because git's merge/branch model is bad and so you need hacks to make it acceptable". Git won, which is why I've been using it for more than 10 years, but that doesn't mean it was ever best, it was just most popular and so the rest of the eco system makes it worth it accepting the flaws (code review tools and CI syste…

Not only is git not the best, but one of the central value props of coding agents and chatbots used for programming is not having to use git in order to interact with free code.

Re: Git Rebase for the Terrified

#202

Post by globular-toast »

> Rebase has a reputation for destroying work, and the warnings you see online don’t help.

Everyone using git needs to accept the following. Say it out aloud if you have to: no command in git can ever modify or delete a commit.

After a botched rebase your old work is one simple reset away using the reflog. Then you can have another go or reach out for help.

Re: Git Rebase for the Terrified

#203

Post by aib »

My default pull is ff-only. I don't like merging or rebasing by default.

When working in a short-lived branch, I like to rebase. I usually get no or simply easy-to-solve conflicts. I like my small and numerous commits stacked on top of the current develop. Regardless or whether we squash or not.

For long-lived branches (and technically for hard merges, though I've been using rerere more and more) merge is a better option.

What kills bisect, IMO, is large commits or commits with multiple subjects/goals. That's the reason I don't like squashed PRs.

Re: Git Rebase for the Terrified

#204

Post by globular-toast »

pluralmonad wrote: post #165
ratchetclank wrote: post #66

Earlier quoted context omitted.

I disagree, without this info, I can't easily tell if any commit is part of a feature or is a simple hotfix. I need to rely on the commiter to include the info in the commit message, which is almost always not the case.

But you are still relying on them to name the branch in such a way it encodes that info. It is unclear why this is superior to messages in commits.

It's worse than that: the branch name is lost after a merge. That "merge branch xyz" is simply the default commit message. So it doesn't matter what you do, commit messages are all you have!

Re: Git Rebase for the Terrified

#205

Post by yxhuvud »

kunley wrote: post #82
yxhuvud wrote: post #74

Earlier quoted context omitted.

I wish github created automation for this flow like they have for other variants.

But they have, with pull requests. When you merge a pull request it is done via the "subtree" merge strategt, which preserves partial commits and also does not flatten them.

There is no button to rebase, and then merge with a merge commit no-ff.

Re: Git Rebase for the Terrified

#206

Post by e40 »

game_the0ry wrote: post #78

I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…

This "debate" is just insane.

Any workflow that has a review process uses rebase. FULL STOP.

If you don't have your code reviewed and you push code to a shared repo, fine, don't use rebase if you don't want to.

Re: Git Rebase for the Terrified

#207

Post by bastardoperator »

drysine wrote: post #195
rpcope1 wrote: post #139

Earlier quoted context omitted.

I have worked on several codebases where it was enforced that the commit be rebased off of whatever the main branch was, all units of work squashed to a single commit, and only "working" code be checked into the main branch. This gives you a really good linear history, and when you're disciplined about writing good final commit messages and tagging them to a ticket, it means bisecting to find challenging bugs later b…

>each commit nominally should work Except it can be the result of 10 squashed commits.

Which is the entire point of it. Why should I look at ten commits when I can look at one and get the same exact data? Why should I pollute my production history for what a is likely a bunch of debugging commits? The branch is a scratchpad, you should feel empowered within your own branch, rebase allows you to be lazy in the development cycle while presenting a nice clean set of changes at the end of it.

Re: Git Rebase for the Terrified

#208

Post by Yeroc »

drysine wrote: post #195
rpcope1 wrote: post #139

Earlier quoted context omitted.

I have worked on several codebases where it was enforced that the commit be rebased off of whatever the main branch was, all units of work squashed to a single commit, and only "working" code be checked into the main branch. This gives you a really good linear history, and when you're disciplined about writing good final commit messages and tagging them to a ticket, it means bisecting to find challenging bugs later b…

>each commit nominally should work Except it can be the result of 10 squashed commits.

Most of those 10 squashed commits likely had commit comments like: "Cleanup based on PR feedback." etc.

Re: Git Rebase for the Terrified

#209

Post by xorcist »

game_the0ry wrote: post #78

I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…

What is the argument here? Does it still hold if you s/rebase/comments/g ?

Of course a readable code history aids in debugging. Just as comments and indentation do. None of these are technically necessary, but still a good idea.

Of course running the rebase command doesn't guarantee a readable commit history, but it's hard to craft commits without it. Each and every commit on linux-kernel has been rebased probably a dozen times.

Re: Git Rebase for the Terrified

#210

Post by bodge5000 »

coffeebeqn wrote: post #2

I wish rebase was taught as the default - I blame the older inferior version control software. It’s honestly easier to reason about a rebase than a merge since it’s so linear. Understanding of local versus origin branch is also missing or mystical to a lot of people and it’s what gives you confidence to mess around and find things out

Funnily enough in all my years of using git, this thread is the first time I've encountered merge. It sounds easier I suppose, but I don't really have a problem with rebase and will likely just continue as is
Post reply on HN