Re-open commit message editing window after a commit is rejected by a commit-msg hook about vim-fugitive HOT 5 CLOSED

From man githooks:

pre-commit
This hook is invoked by git-commit(1), and can be bypassed with the --no-verify option. It takes no parameters, and is invoked before obtaining the proposed commit log message and making a commit.

Please clarify how a pre-commit hook is running after obtaining the proposed commit log message, directly contradicting the documentation.

from vim-fugitive.

When I refer to pre-commit above, I was referring to the pre-commit framework, which despite its name, actually manages all sorts of hooks other than just pre-commit. Perhaps it's a bit confusing, but the actual git hook that https://github.com/alessandrojcm/commitlint-pre-commit-hook is actually intended to installed as a commit-msg hook:

commit-msg

This hook is invoked by git-commit[1] and git-merge[1], and can be bypassed with the --no-verify option. It takes a single parameter, the name of the file that holds the proposed commit log message. Exiting with a non-zero status causes the command to abort.

The hook is allowed to edit the message file in place, and can be used to normalize the message into some project standard format. It can also be used to refuse the commit after inspecting the message file.

The default commit-msg hook, when enabled, detects duplicate Signed-off-by trailers, and aborts the commit if one is found.

This is how you define a .pre-commit-config.yaml for commitlint:

repos:
  - repo: https://github.com/alessandrojcm/commitlint-pre-commit-hook
    rev: v9.4.0
    hooks:
      - id: commitlint
        stages: [commit-msg]

I'll rewrite the issue to emphasize more on commit-msg instead of pre-commit.

from vim-fugitive.

I figured there was more to it than pre-commit, but I had forgotten commit-msg has veto power.

For :Git commit, the answer is a simple "no", as that's trying to be a faithful interface to git commit. But it's not the worst idea for a feature request to git commit itself.

For the c maps, I'm more flexible in theory, but in practice, they're simple wrappers around :Git commit. I'd like to make c a richer experience, and this could be a part of that, but I wouldn't get my hopes up about it happening in the near future.

Nevertheless I'll humor a bit of discussion about it. How can we tell the difference between the commit-msg hook failing, and the other reasons git commit can fail, like an empty message? If we retry unconditionally, that's potentially an infinite loop.

from vim-fugitive.

Thanks for considering. I agree that it may not be easy to convince git commit to distinguish the different kinds of errors and this really requires git commit to implement this mechanism first. I also agree that :Git commit should just be a faithful wrapper for git commit, that makes a lot sense.

I think it should in theory be possible to use git plumbing commands or linking to a library like libgit2 to have fugitive re-implement the steps that git commit did internally, making the commit objects, creating gpg signature (gpg signing is another step where I noticed that you can lose a commit message if the signing fails, e.g. you didn't open your keyring), calling the hooks, etc to have better control over the commit process. But admittedly that seems like it would be a fairly complicated task and it would be brittle too when git commit will inevitably change in the future and likely would cause more problems if fugitive's implementation of git commit doesn't match exactly what git commit does. Unless you already have other things in mind where you would want to do something like that anyway, it may not be worth the maintenance complexity to re-implement git commit inside fugitive just for this feature.

In that light, would it be possible to re-consider the rejection of adding a command/map for creating a new commit while re-editing the last message? Since at least I would have been able to trigger re-doing the commit manually.

from vim-fugitive.

I think it should in theory be possible to use git plumbing commands or linking to a library like libgit2 to have fugitive re-implement the steps that git commit did internally, making the commit objects, creating gpg signature (gpg signing is another step where I noticed that you can lose a commit message if the signing fails, e.g. you didn't open your keyring), calling the hooks, etc to have better control over the commit process. But admittedly that seems like it would be a fairly complicated task and it would be brittle too when git commit will inevitably change in the future and likely would cause more problems if fugitive's implementation of git commit doesn't match exactly what git commit does. Unless you already have other things in mind where you would want to do something like that anyway, it may not be worth the maintenance complexity to re-implement git commit inside fugitive just for this feature.

I'd be interested to know if Magit (or another comparable tool) has anything for this. Skimming the docs, I'm not seeing anything. Magit is much more ambitious than us in creating high level abstractions around low level Git functionality, so if they don't attempt to solve this, I'm inclined to say we shouldn't either.

In that light, would it be possible to re-consider the rejection of adding a command/map for creating a new commit while re-editing the last message? Since at least I would have been able to trigger re-doing the commit manually.

The previously proposed solution was basically :Git commit --edit -F .git/COMMIT_EDITMSG. This map only makes sense immediately after a failure; otherwise it just blindly reuses an old commit message for a new commit. I don't want to provide this; it's too confusing.

But here's a more fleshed out version you can stick in after/ftplugin/fugitive.vim, if you so desire:

nnoremap <buffer> ctc :<C-U>Git commit --edit -F <C-R>=fnameescape(FugitiveGitPath(FugitiveFind('.git/COMMIT_EDITMSG')))<CR><CR>

t as in "try again", I guess. With room to expand to ctA for amending, etc.

from vim-fugitive.