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

21–30 of 305 posts

Re: Git Rebase for the Terrified

#21

Post by _flux »

echelon wrote: post #5
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

git rebase squash as a single commit on a single main branch is the one true way. I know a lot of people want to maintain the history of each PR, but you won't need it in your VCS. You should always be able to roll back main to a real state. Having incremental commits between two working stages creates more confusion during incidents. If you need to consult the work history of transient commits, that can live in your…

Merging merge requests as merge commits (rather than fast-forwarding them) gives the same granularity in the main branch, while preserving the option to have bisect dive inside the original MR to actually find the change that made the interesting change in behavior.

Re: Git Rebase for the Terrified

#22

Post by hnarn »

ngruhn wrote: post #18
hnarn wrote: post #15

Earlier quoted context omitted.

> So I got married first and got a Dog later, right? No. In one reality, you got married with no dog, and in another reality you got a dog and didn't marry. Then you merged those two realities into P. Going "back in time to commit D" is already incorrect phrasing, because you're implying linear history where one does not exist. It's more like you're switching to an alternate past.

The point is that it's harder to reason over.

I don't really agree that it's harder to reason over in the sense that it's hard to understand the consequences, but I also agree that a linear history is superior for troubleshooting, just like another comment pointed out that single squashed commits onto a main branch makes it easier to troubleshoot because you go from a working state to a non-working state between two commits.

Re: Git Rebase for the Terrified

#23

Post by ratchetclank »

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 auto suffix message with the current branch in the text, but it will only work for me, not any contributors...

Re: Git Rebase for the Terrified

#24

Post by agumonkey »

ngruhn wrote: post #18
hnarn wrote: post #15

Earlier quoted context omitted.

> So I got married first and got a Dog later, right? No. In one reality, you got married with no dog, and in another reality you got a dog and didn't marry. Then you merged those two realities into P. Going "back in time to commit D" is already incorrect phrasing, because you're implying linear history where one does not exist. It's more like you're switching to an alternate past.

The point is that it's harder to reason over.

there are others tricky time issues with staging/prod parallel branching models too, the most recent merge (to prod) contains older content, so time slips .. maybe for most people it's obvious but it caused me confusion a few times to compare various docker images

Re: Git Rebase for the Terrified

#25

Post by rich_sasha »

I have lost ~irretrievably work via rebase.

I was working on a local branch, periodically rebasing it to master. All was well, my git history was beautiful etc.

Then down the line I realised something was off. Code that should have been there wasn't. In the end I concluded some automatic commit application while rebasing gobbled up my branch changes. Or frankly, I don't even entirely know what happened (this is my best guess), all I know is, suddenly it wasn't there.

No big deal, right? It's VCS. Just go back in time and get a snapshot of what the repo looked like 2 weeks ago. Ah. Except rebase.

I like a clean linear history as much as the next guy, but in the end I concluded that the only real value of a git repo is telling the truth and keeping the full history of WTF really happened.

You could say I was holding it wrong, that if you just follow this one weird old trick doctor hate, rebase is fine. Maybe. But not rebasing and having a few more squiggles in my git history is a small price to pay for the peace of mind that my code change history is really, really all there.

Nowadays, if something leaves me with a chance that I cannot recreate the repo history at any point in time, I don't bother. Squash commits and keeping the branch around forever are OK in my book, for example. And I always commit with --no-ff. If a commit was never on master, it shouldn't show up in it.

Re: Git Rebase for the Terrified

#26

Post by _flux »

xlii wrote: post #11

Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…

I think I'd love to use Jujutsu, but I enjoy Magit (for Emacs) too much to entertain the thought of switching :/.

Besides, Magit rebasing is also pretty sweet.

Re: Git Rebase for the Terrified

#27

Post by chungy »

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…

Sounds like you'd be a fan of Fossil (https://fossil-scm.org). See for instance: https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...

Re: Git Rebase for the Terrified

#28

Post by tjpnz »

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

I've had recent interns who've struggled with rebase and they've never known anything but Git. Never understood why that was given they seem ok with basic commits and branching. I would agree that rebase is easier to reason about than merging yet I'm still needing to give what feels like a class on it.

Re: Git Rebase for the Terrified

#29

Post by psychoslave »

embedding-shape wrote: post #17

> The response is often hesitation or outright fear. I get it. Rebase has a reputation for destroying work, and the warnings you see online don’t help. The best method for stop being terrified of destructive operations in git when I first learned it, was literally "cp -r $original-repo $new-test-repo && go-to-town". Don't know what will happen when you run `git checkout -- $file` or whatever? Copy the entire director…

One step further which is in-scope-of-the-tool spirit will be git clone locally your repository.

And still one step further, just create a new branch to deal with the rebase/merge.

Yes there are may UX pain points in using git, but it also has the great benefits of extremely cheap and fast branching to experiment.

Re: Git Rebase for the Terrified

#30

Post by nh2 »

rich_sasha wrote: post #25

I have lost ~irretrievably work via rebase. I was working on a local branch, periodically rebasing it to master. All was well, my git history was beautiful etc. Then down the line I realised something was off. Code that should have been there wasn't. In the end I concluded some automatic commit application while rebasing gobbled up my branch changes. Or frankly, I don't even entirely know what happened (this is my be…

> Just go back in time and get a snapshot of what the repo looked like 2 weeks ago. Ah. Except rebase.

This is false.

Any googling of "git undo rebase" will immediately point out that the git reflog stores all rebase history for convenient undoing.

Shockingly, got being a VCS has version control for the... versions of things you create in it, not matter if via merge or rebase or cherry-pick or whatever. You can of course undo all of that.

Post reply on HN