Days since I messed up a conflict resolution during git rebase by using "git commit --amend" instead of "git rebase --continue", which squashes the fixed up commit into the previous one: 0

Sigh, does anyone have some trick that detects this situation and fails the --amend? :))

@vbabka I wouldn't expect git to be able to deny you your wish to amend (although there are a lot of config options).

And while you probably could hack some files in .git, take refs from reflog, set some tags and thus restore the pre-amend state manually, in many cases it is probably still harder than doing the whole rebase again…

git rerere could be useful, but I have exactly zero experience with that yet.

@vbabka

Reading this toot is like feeling old paper cuts re-opening

@vbabka

Git reflog covers multitude of sins?

Pre commit hook to scan for one of the conflict section markers?
Not tried it but might work

Markers like <<<< or >>>> or ====
I'm sure you get it
@vbabka

@p @vbabka I'm afraid you're missing the point. There were no conflict markers, but the resolved working tree should become a new commit, not be merged with the last commit on the branch.

@vbabka I believe you can still get the old commit OID before the amend. From that, recover the non-squashed old commit, then restore the working tree from the amended tree OID and commit it as a merge commit ("git rebase --continue"). I haven't checked this idea, but it should work.

>> the fixed up commit

Yes is see, only answer is to make a backup branch or dont make mistakes

@ptesarik
@vbabka

@vbabka How did you even arrive there? I have tried to verify my idea and I'm running into this:

petr@mordecai:~/research/botch-up-merge> git commit --amend
fatal: You are in the middle of a merge -- cannot amend.

git version 2.45.2

@ptesarik it seems you're trying this with a merge, not rebase?

@vbabka Doh, right, I'm blind. 🙈

@ptesarik @mcepl yes it's possible to recover and git reflog is crucial for that, but still would be nicer to prevent it in the first place.

@vbabka @a1ba I tend to "git reset --soft HEAD^" when I'm rebasing commits to split them apart if I grouped up things I shouldn't have.

Is that possibly applicable to your intent?

@vbabka @mcepl I agree. I don't understand why git's parse_and_validate_options() does not check being in the middle of a rebase.

No pre-commit hook can achieve the goal, because it should fail only if .git/REBASE_HEAD exists _and_ the --amend option is used.

@lispi314 @a1ba kinda, but it's more like things were already apart and now accidentally squashed together. It would be better to prevent this, not fix up. Here it's in more detail: https://jvns.ca/blog/2023/11/06/rebasing-what-can-go-wrong-/#accidentally-run-git-commit-amend-instead-of-git-rebase-continue

@ptesarik @mcepl in other times it's valid to amend during rebase, i.e. when editing a commit. It's just this weird state during the conflict resolution where the "current commit" is still the previous one, but the work tree is already the next one (with conflict), and the commit log of that next commit is $somewhere, and amend just makes a mess of it. Hopefully git should be able to know it's in the state (maybe thanks to the "commit log of that next commit is $somewhere" part?) and deny the amend. Even if it's a non-default config option so it doesn't break other use cases, I'd gladly enable it.

@vbabka git reflog and git reset —hard the previous if in middle of rebase

@vbabka ive used it at least countless times when doing the same exact mistake. Rebase just on top of whatever is the underlying git tree. It is in that way stateless

@vbabka have you tried replacing git with cat in all of your commands?

Cats are lovely furry creatures and, while they can scratch you, and sometimes bite, they are usually sweet and innocent. And you can stroke them!

@vbabka KNOW
THAT
FEEL
BRO

@ptesarik @vbabka well you could be barefoot

@vbabka AFAIK or at least for my practical use reflog is can be translated as "undo log" and resetting to any state in it does not mix up rebase state. It will just continue whatever is underneath. Definitely a worthwhile git sub-command to learn properly...

@vbabka @mcepl @ptesarik i felt like #git completely let me down and doesn't care about me any more when i attempted to commit everything with a commit message of "end" and git went:

$ git commit -amend
error: did you mean `--amend` (with two dashes)?

@vbabka put this in your .bashrc or something?

git() {
if [ -e "$(command git rev-parse --git-dir)/rebase-merge" ] && (echo "$@" | grep -q "\--amend")
then
echo "error: you tried to do git commit --amend during a conflict resolution, didn't you?"
return 1
fi
command git "$@"
}

@vbabka Forgot one thing: HEAD@{<index>} can be used to index the reflog entries. It is nice because it is just a bookmark list where new bookmark gets added when ever there is a new commit ID. It is nothing retained in the version control itself.

@vegard almost, as that triggers in all situations during rebase, such as editing a commit, where --amend is very much useful, and not only when rebase is stopped due to conflict and --amend is dangerous

@vbabka How about this?

git() {
git_dir="$(command git rev-parse --git-dir)"
if [ -e "$git_dir/rebase-merge" ] && [ -e "$git_dir/MERGE_MSG" ] && (echo "$@" | grep -q "\--amend")
then
echo "error: you tried to do git commit --amend during a conflict resolution, didn't you?"
return 1
fi
command git "$@"
}

@vegard looks much better, thanks a lot!

@vbabka @vegard You don't need to use amend while editing a commit during a rebase. Once you've made changes you add them with `git add` and then `git rebase --continue` will do the amend for you.

@mpe @vegard but it also proceeds with the rebase, while I often amend, git show the result, then might tweak with more amends...