71–80 of 155 posts
Earlier quoted context omitted.
> as long as I keep their hashes that means my hashes or their hashes or them keeping my hashes, I am never sure
you can just make a backup copy of .git or your entire project dir. When you get lost, just delete your .git, copy from the backup and try again
One additional thing I would mention ist that: When resolving conflicts never try to solve them for the final result. Consider each conflict without considering how the code will change in a later commit. I’ve seen people die a painful rebase death because of this.
Earlier 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…
I'm genuinely unsure why rebase interactive is more scary than rebase
I feel like if you're scared of rebasing, you don't actually understand git.
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…
One additional thing I would mention ist that: When resolving conflicts never try to solve them for the final result. Consider each conflict without considering how the code will change in a later commit. I’ve seen people die a painful rebase death because of this.
rerere
Earlier quoted context omitted.
> as long as I keep their hashes that means my hashes or their hashes or them keeping my hashes, I am never sure
you can just make a backup copy of .git or your entire project dir. When you get lost, just delete your .git, copy from the backup and try again
The opposite is true, of course, for example: you move commits arround, start to resolve conflicts, and after a few steps you realize you can't, so when you
> you can bail out at any time. as aforementioned with git rebase --abort
Yep, except for all the work you've done resolving the conflict, that's "aborted"
> the old commits still exist in git’s object database, unreferenced but intact,
The best UI there is - some hidded data store you're, of course, intimately familiar with, so won't have any trouble getting data out of. Oh, wait, you didn't even know it existed? Tough luck, git gud to avoid data loss!
> botched rebase is a few minutes of you perusing through the reflog.
Unless, of course, your not that sharp to remember all the commits from their names and would also like to see the diff contents to connect to your code work. But that's just more minutes extra, not that big of a loss.
> there’s of course, the low-tech insurance policy: git branch backup-before-rebase
Finally some sensible advice, one that should be the default backup plan to save userst he trouble of wasting "few minutes" perusing the logs
Earlier 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
Earlier quoted context omitted.
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…
Give it an hour or two. It is really not that complicated. A little bit of investment will pay huge dividends. Do yourself the favor.
1. Everyone uses feature branches
2. Everyone cleans up their branch using interactive rebase on top of main before review
3. All merges have been freshly rebase on main
I think it works very well and keeps the history clean while preserving "each commit does one thing".