The HN title is "Git rebase -I etc" but the post title is "Git rebase -i"
I guess a keyboard auto corrected i into I.
Git rebase -i is not that scary
111–120 of 155 posts
Re: Git rebase -i is not that scary
#112I use interactive rebases frequently, but even then, I think conflicts happening during a rebase are often somewhat cryptic. I think I know what happens in principle (each step of a rebase does a merge of the commit from the list with the last rebased commit) but it's still often hard to understand which side of the conflict represents what, and what would be the desired outcome for that step in the history . So I te…
> but it's still often hard to understand which side of the conflict represents what, and what would be the desired outcome for that step in the history. Are you using diff3/zdiff3? I ask because you seem to be describing exactly the problem it solves, or at least the way I try to sell people on it. Basically in addition to 'current' & 'incoming from the rebase' hunks you get 'parent commit of incoming from the rebas…
Thanks for the info! I didn't try that so far, but it sounds like it could really make that easier. Will give it a try!
Re: Git rebase -i is not that scary
#113I use interactive rebases frequently, but even then, I think conflicts happening during a rebase are often somewhat cryptic. I think I know what happens in principle (each step of a rebase does a merge of the commit from the list with the last rebased commit) but it's still often hard to understand which side of the conflict represents what, and what would be the desired outcome for that step in the history . So I te…
In case of many commits with also many complex merge conflicts, I often find it easier to just:
1. Abort rebase.
2. Squash all my commits into a single commit.
3. Rebase on target branch again.
Re: Git rebase -i is not that scary
#114I’ve used Git for 20 years now and wrote a book about it. The biggest mistake most sources make when teaching about history rewriting is omitting these two lessons first: - it’s easy to lose uncommitted data in Git and hard to lose committed data - given this, learn how to use ‘git reflog’ to see what you’ve done and how to undo/redo it (as this post recommends but, even then, a little too late) If you just get in th…
> (Related lesson from my 10 years employed by GitHub: they almost never do the git gc you’d expect to remove commits so once you push a commit: it’s likely there forever and identifiable by that same hash from anywhere in the fork network. This can be bad/scary so be aware). Oh wow. Is there a way to trigger GC manually?
For github itself the answer is "contact them if you think you pushed a secret".
For git. You can run `git maintenance run` or the legacy command `git gc`.
Re: Git rebase -i is not that scary
#115After two decades of using git I'm either telling LLMs to do rebases for me or use jj (or both). Life's too short.
Re: Git rebase -i is not that scary
#116Earlier quoted context omitted.
When I interview someone and they are scared of `git rebase -i` it's a huge red flag. Git rebase has such foundational data structures and concepts that you couldn't pass a serious college programming course without grokking it. The only reason someone would be scared of git rebase is: a) they don't know the basics of programming/software engineering b) they are not intellectually curious enough to look into how tf t…
An interviewer asking me about git rebase is the huge red flag
Understanding git rebase is important. You aren't expected to rebase mainline branches regularly but if your team operates on a merge/patchset workflow and isn't just squashing everything down onto main each PR you need to understand how to rebase your changes.
You do your development and use rebase to organise your code into logical commits/patches that can each be reviewed separately. This way when you do your review in github or on the mailing list or whatever you can review each logical change by going through and reviewing the commits separately (which you can do in github by selecting the commit in the dropdown for the review window).
And of course via email based workflows or "stacked patchset" workflows like what tangled provides then you can get deltas between revisions so that you can see what changed in a given commit between rev 1 and rev 2 so that you don't have to re-review the entire patchset/PR, only the stuff that matters (but still broken up into logical changes).
Re: Git rebase -i is not that scary
#117Earlier quoted context omitted.
It could be so much better. At the same time, it’s one of the core tools for a developer. You’ll learn it eventually. You’re going to be using version control for decades. I’ve met devs many years into their careers who don’t understand rebase. It’s like going to a metal shop and they’re complaining about the learning curve on their welder and half the tradesmen are still at a novice level.
I still don't know it very well, and it's been well over a decade. I think it's a combination of a few things: - I find it uninteresting. My version control needs are very simple. - Most teams I have been in use a small subset of it. - It's confusing terms and inconsistent cli are huge warning signs to not go down that rabbithole. Today instead of learning Git I read some Tony Hoare, much better. I've been at once pl…
Have you ever read any of the introductory material that the git project itself maintains for teaching how to use the tool?
- https://git-scm.com/docs/gittutorial
- https://git-scm.com/docs/giteveryday
- https://git-scm.com/docs/gitworkflows
- https://git-scm.com/docs/gitfaq
- https://git-scm.com/cheat-sheet
Or if you want to sit down and really learn the nuts and bolts
Re: Git rebase -i is not that scary
#118Earlier quoted context omitted.
The part where git needs to be “understood” is the entire problem. “Do one thing and do it well” was the whole mantra, which was completely ignored with the disaster that is git. It’s objectively awful.
yeah I would really love to see a subset of git with a sane cli. would switch in a heartbeat.
Git has been re-designing their tooling over the last few years. Nowadays there exist really pleasant, easy to use versions of the main tools.
switch and restore replaced checkout. history is being developed to replace rebase for most common use cases. maintenance replaces gc. etc.
Re: Git rebase -i is not that scary
#119After two decades of using git I'm either telling LLMs to do rebases for me or use jj (or both). Life's too short.
Just make sure you've committed and/or stashed first, as you don't really want to rely on the stochastic process to retain your local-only critical work product.
Re: Git rebase -i is not that scary
#120I found the following config to bring a great QoL improvement: FILE: .gitconfig ---------------- [alias] ci = commit fix = commit --fixup [rebase] autosquash = true Now you can do quick commits as save-points, and squash all of them at the end. git tag last-good git ci -am 'WIP' git fix HEAD -a git fix HEAD -a … git rebase -i last-good
It's not recommended because you can just use the --autosquash flag. No reason to make it the default.
especially since if you are rebasing you may want to rebase your changes from one branch to another (i.e. move to top of main or from on top of one feature to another).
So instead you can just do git rebase --autosquash -i last-good or just git rebase --autosquash and let it squash it down for you.