Sean Allred <allred.sean@xxxxxxxxx> writes: > Is there a current reason why pre-commit shouldn't be invoked during > rebase, or is this just waiting for a reviewable patch? > > This was brought up before at [1] in 2015, but that thread so old at > this point that it seemed prudent to double-check before investing time > in a developing and testing a patch. > > [1]: https://lore.kernel.org/git/1m55i3m.1fum4zo1fpnhncM%25lists@xxxxxxxxxxxxxxxx/ If you are trying to make it less likely that your developers would commit conflict markers by mistake, I think an effective way would be to give "git rebase" an option (or a configuration variable) that forbids it from making a new commit upon "git rebase --continue", which AFAIK was added merely to help "lazy" folks to omit the explicit "git commit" step in the following sequence: $ git rebase origin/master ... stops with conflicts $ edit ... now the conflicts are resolved (and hopefully you have ... tested the result) $ git commit $ git rebase --continue
