4 ms·
I love rebase (I'm a tip-of-master-only person, no merges ever, squash all your commits with `rebase -i` before pushing and write one good commit message for th
by ajkjk 3y ago
I love rebase (I'm a tip-of-master-only person, no merges ever, squash all your commits with `rebase -i` before pushing and write one good commit message for the group). But there's one really, really irritating thing about them:
You should not be able to use `--amend` during a rebase.
For me editing all my changes onto the commit I'm working on with `git commit -a --amend` (or as I've aliased it, `gcaa`) is automatic; I do it 500 times a day, just to save my work. But I can't count how many times I've been in the middle of squashing commits and accidentally typed `gcaa` and amended someone else's commit after fixing a merge conflict, and it's super annoying to unwind (if you realize after typing `rebase --continue`) so usually I end up just giving up and starting over. I really wish amending to a commit that wasn't one of the ones you're rebasing was just totally disabled.
I guess there are some other small complaints, like the annoying reversing of `--ours` and `--theirs` from what makes sense (yes, it makes sense if you have the internal model of rebase instead of the intuitive one, but that's stupid), rebase's tendency to pick the wrong parent commit if you've accidentally amended someone else's commit (and therefore lag a while and then produce a rebase log of 1000 commits or something), and the utter tedium of editing the rebase log to replace every instance of "pick" with "s" for squash except the first, since almost 100% of the time what I want to do is squash everything (and use the last commit message, not the first, and definitely not all of them munged together which is the default).
I would love a separate command or a flag, like "git rebase --tip" that does all of this automatically for my otherwise extremely elegant workflow (and I'm gonna be really bummed if it turns out it exists and I didn't know about it for the last 5 years...).
- ksenzee 3y agoI’m curious how this workflow differs from `git merge --squash`.
- ajkjk 3y agoI dunno, I've literally never used merge ever since realizing what it does to the commit history.
- ksenzee 3y agoThen you should probably look up squash “merges,” because I believe that’s your `git rebase --tip`. I use quotation marks because it’s not an actual merge. It just takes all the changes from the feature branch and stages them in the index, ready for you to commit as one single non-merge commit.
- mbakke 3y agoI have a similar workflow, but make a bunch of commits with "git commit --fixup HEAD". (Or --squash REF). Then on the final rebase the commits are automatically ordered with s and f as appropriate. Although I do a fair bit of amending, too.
- qhwudbebd 3y agoRandom thought: given you already have the gcaa alias, perhaps you could include a check that .git/REBASE_HEAD doesn't exist in that? Probably easiest as a little shell function like gcca() { local GIT_DIR if ! GIT_DIR=$(git rev-parse --git-dir); then return 1 elif test -f "$GIT_DIR/REBASE_HEAD"; then printf 'Rebase in progress: commit --amend is disabled\n' >&2 return 1 fi git commit -a --amend "$@" } rather than an alias? [Edit] I forgot about rev-parse --verify, which simplifies this further: gcca() { if git rev-parse --verify REBASE_HEAD >/dev/null 2>&1; then printf 'Rebase in progress: commit --amend is disabled\n' >&2 return 1 fi git commit -a --amend "$@" } This also leaves you still able to use commit --amend long-hand if (for example) you want to edit one of your own commits during rebase -i.
- nicwolff 3y agoDude your "random thoughts" are better than a lot of folks' work output ツ
- ajkjk 3y agoThat's a great idea. Git problems are sorta in the category of problems I've avoided trying to solve because, can't solve everything, and I've been hacking around it successfully instead.
- latexr 3y agoYou can shorten `>/dev/null 2>&1` to `&>/dev/null`.
- abdusco 3y ago> accidentally typed gcaa and amended someone else's commit after fixing a merge conflict You could try reverting the first commit on the HEAD once you finish the rebase. This is of course assuming your branch and the last commit don't touch the same files.
- conaclos 3y agoI also encounter this issue. I would also like to forbid amendind a commit that is not part of the working branch.