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

31–40 of 305 posts

Re: Git Rebase for the Terrified

#31

Post by codesnik »

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…

whoa. well, if it really works for you. The thing is, git has practically zero "destructive" commands, you almost always (unless you called garbage collector aggressively) return to the previous state of anything committed to it. `git reflog` is a good starting point.

I think i've seen someone coded user-friendlier `git undo` front for it.

Re: Git Rebase for the Terrified

#32

Post by rich_sasha »

nh2 wrote: post #30
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 co…

Up to a point - they are garbage collected, right?

And anyway, I don't want to dig this deep in git internals. I just want my true history.

Another way of looking at it is that given real history, you can always represent it more cleanly. But without it you can never really piece together what happened.

Re: Git Rebase for the Terrified

#33

Post by Zambyte »

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…

Also been using Jujutsu for about 2 years. I feel like I have learned so much about how git actually works by simply not using git.

Re: Git Rebase for the Terrified

#34

Post by fc417fc802 »

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…

> You should always be able to roll back main to a real state.

Well there's your problem. Why are you assuming there are non-working commits in the history with a merge based workflow? If you really need to make an incremental commit at a point where the build is broken you can always squash prior to merge. There's no reason to conflate "non-working commits" and "merge based workflow".

Why go out of the way to obfuscate the pathway the development process took? Depending on the complexity of the task the merge operation itself can introduce its own bugs as incompatible changes to the source get reconciled. It's useful to be able to examine each finished feature in isolation and then again after the merge.

> with all the other metadata (such as review comments and diagrams/figures) that never make it into source control.

I hate that all of that is omitted. It can be invaluable when debugging. More generally I personally think the tools we have are still extremely subpar compared to what they could be.

Re: Git Rebase for the Terrified

#35

Post by codesnik »

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…

it's just "gitflow" is unnecessary complex (for most applications). with rebase you can work more or less as with "patches" and a single master, like many projects did in 90x, just much more comfortably and securely.

Re: Git Rebase for the Terrified

#36

Post by pabs3 »

git rebase conflict resolution is a lot less scary with the zdiff3 merge.conflictStyle option.

Also incremental rebasing with mergify/git-imerge/git-mergify-rebase/etc is really helpful for long-lived branches that aren't merged upstream.

https://github.com/brooksdavis/mergify https://github.com/mhagger/git-imerge https://github.com/CTSRD-CHERI/git-mergify-rebase https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

I also love git-absorb for automatic fixups of a commit stack.

https://github.com/tummychow/git-absorb

Re: Git Rebase for the Terrified

#37

Post by huflungdung »

codesnik wrote: post #31
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…

whoa. well, if it really works for you. The thing is, git has practically zero "destructive" commands, you almost always (unless you called garbage collector aggressively) return to the previous state of anything committed to it. `git reflog` is a good starting point. I think i've seen someone coded user-friendlier `git undo` front for it.

[dead]

Re: Git Rebase for the Terrified

#38

Post by bob1029 »

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…

The fastest way to eliminate fear is to practice. I had the team go through it one day. They didn't get a choice. I locked us on a screen share until everyone was comfortable with how rebasing works. The call lasted maybe 90 minutes. You just have to decide one day that you (or the team) will master this shit, spend a few hours doing it, and move on.

Rebase is a super power but there are a few ground rules to follow that can make it go a lot better. Doing things across many smaller commits can make rebase less painful downstream. One of the most important things is to learn that sometimes a rebase is not really feasible. This isn't a sign that your tools are lacking. This is a sign that you've perhaps deviated so far that you need to reevaluate your organization of labor.

Re: Git Rebase for the Terrified

#40

Post by smartmic »

chungy wrote: post #27
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#...

Let me expand on this with a link to the article "Rebase Considered Harmful" [0].

I also prefer Fossil to Git whenever possible, especially for small or personal projects.

[0] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

Post reply on HN