121–130 of 155 posts
I 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
I feel like if you're scared of rebasing, you don't actually understand git.
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…
Imagine bushwhacking your way through a bunch of conflicts while rebasing on main... Now you realized that you needed to do some other work before your pr is ready for review... Now you need to rebase on main again and get to relive conflict hell again.
Maybe I'm one of the stupid incompetent people referred to in this post but I haven't figured out a way to deal with the having to solve the same merge conflicts when I rebase again :(
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 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.
git config core.editor "vim"
Yeah it's not scary but it can be frustrating... Imagine bushwhacking your way through a bunch of conflicts while rebasing on main... Now you realized that you needed to do some other work before your pr is ready for review... Now you need to rebase on main again and get to relive conflict hell again. Maybe I'm one of the stupid incompetent people referred to in this post but I haven't figured out a way to deal with…
- create an empty commit with the branch name, type, ticket number etc. (with a small git script, `git issue 321 fix some things` -> `git switch -c 321-fix-some-things && git commit -m "fix(321): some things" --allow-empty`)
- `rebase -i` then shines when you have stacked commits where previous one have been merged _in a changed form (e.g. squashed)_. In such cases git often duplicates the already merged commits thinking they are part of your branch leading to endless dump conflicts, with a "marker" commit you can easily spot it in the `rebase -i` view and then also easily stripp them out by removing their lines
Yeah it's not scary but it can be frustrating... Imagine bushwhacking your way through a bunch of conflicts while rebasing on main... Now you realized that you needed to do some other work before your pr is ready for review... Now you need to rebase on main again and get to relive conflict hell again. Maybe I'm one of the stupid incompetent people referred to in this post but I haven't figured out a way to deal with…
git rerere?
I feel like if you're scared of rebasing, you don't actually understand git.
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…
Earlier 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.
Absolutely everything in computing needs to be 'understood' to be used.
You’re very incorrect.