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

151–160 of 305 posts

Re: Git Rebase for the Terrified

#151

Post by PaulDavisThe1st »

DHRicoF wrote: post #142
Akranazon wrote: post #3

Earlier quoted context omitted.

The end result of a git rebase is arguably superior. However, I don't do it, because the process of running git rebase is a complete hassle. git merge is one-shot, whereas git rebase replays commits one-by-one. Replaying commits one-by-one is like a history quiz. It forces me to remember what was going on a week ago when I did commit #23 out of 45. I'm grateful that git stores that history for me when I need it, but…

Then is not rebase your problem, but all your other practices. Long lived feature branches with lot's of unorganized commits with low cohesion. Sometimes it's ok to work like this, but you asking git not being judgamental is like saying your roomba should accomodate to you didin't asking you to empty it's dust bag.

You can make long lived feature branches work with rebase, you just have to regularly rebase along the way.

I had a branch that lived for more than a year, ended up with 800+ commits on it. I rebased along the way, and the predictably the final merge was smooth and easy.

Re: Git Rebase for the Terrified

#152

Post by ivanjermakov »

tomaytotomato wrote: post #41

Github is not Git but I find the Squash and Merge functionality on Github's Pull Request system means I no longer need to worry about rebasing or squashing my commits locally before rebasing. At work though it is still encouraged to rebase, and I have sometimes forgotten to squash and then had to abort, or just suck it up and resolve conflicts from my many local commits.

Squash is not Github specific and is part of git:

    git merge --squash

Re: Git Rebase for the Terrified

#153

Post by mathisfun123 »

jimbobimbo wrote: post #141

Rebase is easy and not terrifying. Here's a 1k word article on how to do it correctly. Or just do a merge and move on with your life.

> Here's a 1k word article

lol if 1k words is "not easy" for you, i think you have bigger problems than merge vs rebase.

Re: Git Rebase for the Terrified

#154

Post by PaulDavisThe1st »

z3dd wrote: post #128
mr_mitm wrote: post #45

Earlier quoted context omitted.

Is there a reason why that recommendation cannot be changed to "don't ever force push unless you are certain no one else has fetched this branch"?

Well that's a distinction which makes sense in theory but is not realistic in practice for most projects with multiple contributors.

Over at ardour.org, we've never had an issue with this practice. Two core full time devs, dozens of others.

Re: Git Rebase for the Terrified

#155

Post by eichin »

mr_mitm wrote: post #45
thibaut_barrere wrote: post #4

PSA: I’m not terrified of rebase, yet it’s good to know this: https://docs.github.com/en/get-started/using-git/about-git-r... > Warning - Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository. A similar warning is in Atlassian docs.

Is there a reason why that recommendation cannot be changed to "don't ever force push unless you are certain no one else has fetched this branch"?

"fetched this branch" needs to include "started reviewing the PR", and probably other cases; it does mean switching modes for devs who usually rebase privately.

Re: Git Rebase for the Terrified

#156

Post by fatbird »

ratchetclank wrote: post #23

I never understood why rebase is such a staple in the git world. For me "loosing" historical data, like on which branch my work was done is a real issue. In the same class, for commit to not have on which branch they were created as a metadata is a rel painpoint. It always a mess to find what commit were done for what global feature/bugfix in a global gitflow process... I'll probably be looking into adding an commit…

Every commit message starts with the ticket number of whatever issue tracking system you're using. If you're not using issue tracking with a system large enough for multiple devs, you've got a much bigger problem.

Re: Git Rebase for the Terrified

#157

Post by rendaw »

alemanek wrote: post #107
hnben wrote: post #100

Earlier quoted context omitted.

> I can give you an example of when I am glad I rebased I think the question was about situations where you were glad to rebase, when you could have merged instead

They kind of spoke to it. Rebasing to bring in changes from main to a feature branch which is a bit longer running keeps all your changes together. All the commits for your feature get popped on top the commits you brought in from main. When you are putting together your PR you can more easily squash your commits together and fix up your commit history before putting it out for review. It is a preference thing for su…

You can bring in changes and address conflicts early with merge too, I believe that's GP's point.

Re: Git Rebase for the Terrified

#158

Post by darknavi »

Aperocky wrote: post #134
kps wrote: post #72

Earlier quoted context omitted.

And `jj undo`, so nothing is terrifying.

well git reflog is that, annoying, yes, but we have LLM so I don't actually need to remember how all the command syntax exactly like back in 2019.

Is git reflog that bad to use? It just lists a bunch of commit hashes. Find the one you want and hard reset to it.

Re: Git Rebase for the Terrified

#159

Post by darknavi »

jimbobimbo wrote: post #141

Rebase is easy and not terrifying. Here's a 1k word article on how to do it correctly. Or just do a merge and move on with your life.

It's funny because I learned git on the job and we exclusively used rebase when I was learning my git fundamentals. I wouldn't say merging scares be, but it's never a tool a reach for.

Re: Git Rebase for the Terrified

#160

Post by skribanto »

friedbeef wrote: post #147
languid-photic wrote: post #129

Earlier quoted context omitted.

I manage a maintained fork and periodically rebase our changes on top of upstream. In this case, rebasing is nice because our changes stay in a contiguous block at the top (vs merging which would interleave them), so it's easy for me and others to see exactly where our fork diverges.

Doesn’t that mean you have to fix all the merge conflicts introduced by your commits on every rebase though?

rerere can help, but OP probably has their own workflow
Post reply on HN