My fear has never been rebasing itself, but that I make some kind of mistake with a random change conflict and don't notice it because it's not tested for directly. But I'm also not sure if that's categorically a git fear. (Edit: related to this, I think this sort of minor "itchy worry" is grounded in how sometimes conceptually simple diffs look messy during conflict resolution.)
If all I'm doing with git rebase is reorganising my commits, and I have to deal with conflicts, after I'm done, I always git diff my pre-rebase head with post rebase head commit hash. I can quickly see I've messed something up if the diff isn't empty. For more complex tasks it's best to leave the rearranging until last, but where not possible, the diff is still pretty useful to double check my work.
made most of my fears regarding conflict resolution go away, as it right away gives me the stuff that I used to look for manually to understand the context of the conflict, which was probably the most error prone part of the process.
Like all git operations that destroy history, it's a bit less scary than rm or unlink, because you can undo obvious fuckups using the reflog. Non-obvious fuckups will (by Murphy's law) only be detected long after the reflog has been GC'd, so it still risks losing work.
Git was written with Linux in mind, where curating a clean commit history is more important than the code itself and warrants the extra hassle.
An actually usable rebase would probably require something like a meta history. But then the meta history would accumulate fixup "commits" and typos in commit messages so the OCD people will want to change that and we're back to square one.
In practice, the two times per decade it actually makes business sense to dig through the history to find when a bug was introduced instead of just writing the 5-line fix, you can live with a couple of imperfect commits and merges.
Reflog is, as the article says, the permission to do all kinds of crazy things, including rebasing. Once you realize any committed state is recoverable for a good period of time it really frees you.
Plus you can always take a note of the commit hash before you do anything crazy. But reflog means you don't have to.
Git really does have all the features you need. I wouldn't argue with anyone complaining about the UI to get there. But it's all in there somewhere.
I think the only missing thing for me would be to group commits, essentially squashing them for a clean history while allowing to unsquash them in case you need it.
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 the software they use every day works
You probably shouldn't have engineers like that on your team.
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).
I wonder if it's because it opens in the default visual editor (typically vi/vim) and while I'm primarily a (neo)vim user now, it is certainly not the most intuitive editor to get started with without guidance.
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.
Really? How familiar are you with how inodes work on a spinning platter vs an eMMC? Can you speak intelligently about how virtual machines segregate their ram boundaries whilst still maintaining decent performance? What is your familiarity with FIPS?
You only have to learn three things to use a computer: Your shell, your editor, and your version control system.
That's it. That basic knowledge will carry you far, and will be useful a decade from now. Those are the three best afternoons you can spend. Do it out of respect for the computer.
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 place where they rebased, and it was awful. Complete waste of time. (great place otherwise though)
This notion that `git rebase -i` is some scary unusual thing is totally alien to me. Doing some minor cleanup on local history with rebase is a *basic* operation that I would have thought everyone would be using regularly.
My fear has never been rebasing itself, but that I make some kind of mistake with a random change conflict and don't notice it because it's not tested for directly. But I'm also not sure if that's categorically a git fear. (Edit: related to this, I think this sort of minor "itchy worry" is grounded in how sometimes conceptually simple diffs look messy during conflict resolution.)
If all I'm doing with git rebase is reorganising my commits, and I have to deal with conflicts, after I'm done, I always git diff my pre-rebase head with post rebase head commit hash. I can quickly see I've messed something up if the diff isn't empty. For more complex tasks it's best to leave the rearranging until last, but where not possible, the diff is still pretty useful to double check my work.
range-diff can be useful for that too.
Setting:
made most of my fears regarding conflict resolution go away, as it right away gives me the stuff that I used to look for manually to understand the context of the conflict, which was probably the most error prone part of the process.
Like all git operations that destroy history, it's a bit less scary than rm or unlink, because you can undo obvious fuckups using the reflog. Non-obvious fuckups will (by Murphy's law) only be detected long after the reflog has been GC'd, so it still risks losing work.
Git was written with Linux in mind, where curating a clean commit history is more important than the code itself and warrants the extra hassle.
An actually usable rebase would probably require something like a meta history. But then the meta history would accumulate fixup "commits" and typos in commit messages so the OCD people will want to change that and we're back to square one. In practice, the two times per decade it actually makes business sense to dig through the history to find when a bug was introduced instead of just writing the 5-line fix, you can live with a couple of imperfect commits and merges.
Reflog is, as the article says, the permission to do all kinds of crazy things, including rebasing. Once you realize any committed state is recoverable for a good period of time it really frees you.
Plus you can always take a note of the commit hash before you do anything crazy. But reflog means you don't have to.
Git really does have all the features you need. I wouldn't argue with anyone complaining about the UI to get there. But it's all in there somewhere.
I think the only missing thing for me would be to group commits, essentially squashing them for a clean history while allowing to unsquash them in case you need it.
git reflog can only help if the reflog history hasn't expired and been removed by a maintenance run.
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:
You probably shouldn't have engineers like that on your team.
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).
Genuine question, why? It seems like a reasonable knowledge check that can be answered in a few sentences.
I wonder if it's because it opens in the default visual editor (typically vi/vim) and while I'm primarily a (neo)vim user now, it is certainly not the most intuitive editor to get started with without guidance.
You can always set the editor in your --global or --local config though:
I do agree that using the default editor is a mostly a bad choice due to it being vi/vim rather often.
1 reply →
I'm genuinely unsure why rebase interactive is more scary than rebase
Yeah I never use non-interactive rebase. Even if I don't need to edit the todo list, reading it gives me a confirmation of what git will do.
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.
Absolutely everything in computing needs to be 'understood' to be used.
Really? How familiar are you with how inodes work on a spinning platter vs an eMMC? Can you speak intelligently about how virtual machines segregate their ram boundaries whilst still maintaining decent performance? What is your familiarity with FIPS?
You’re very incorrect.
5 replies →
You only have to learn three things to use a computer: Your shell, your editor, and your version control system.
That's it. That basic knowledge will carry you far, and will be useful a decade from now. Those are the three best afternoons you can spend. Do it out of respect for the computer.
I am gainfully employed because I’m decent at those 3 things. I’m not sure why you assume I’m not. Fair point though.
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.
Fossil?
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 place where they rebased, and it was awful. Complete waste of time. (great place otherwise though)
5 replies →
[dead]
sounds like someone accidentally delete your repo because they didn't understand git and did a dumdum :P
[flagged]
This notion that `git rebase -i` is some scary unusual thing is totally alien to me. Doing some minor cleanup on local history with rebase is a *basic* operation that I would have thought everyone would be using regularly.
I'm not scared of rebasing I'm scared of force pushing
Correct on both counts.