[Qt-creator] prepare-commit-msg and commit-msg hooks

[Seth Raymond]

> so this is really an inherent problem of the fact that the dialog
> parallelizes a workflow that is meant to be sequential.

This is the underlying problem. I'm sure there are plenty of inelegant
workarounds, but they're exactly that - inelegant. Furthermore, these
workarounds can't be done at the user-level, they must be a
(relatively) significant change to Creator/the git plugin.

I think the solution boils down to two options: either overhaul how
the git plugin handles the flow or circumvent a portion of git's
back-end and recreate it in the plugin. Is there a strong reason to
keep the process in its current, parallelized state?

On Tue, Jan 9, 2018 at 7:05 AM, Oswald Buddenhagen
<oswald.buddenhagen at qt.io> wrote:
> On Tue, Jan 09, 2018 at 01:19:33PM +0200, Orgad Shaneh wrote:
>>    What if there are no staged files? git commit will not execute any hook on
>>    this case,
>>
> it can be forced with --allow-empty.
>
>>    and this is the typical state when the Git Commit dialog is opened.
>>
> well, yes, and the hook's output can depend on what has been staged.
> so this is really an inherent problem of the fact that the dialog
> parallelizes a workflow that is meant to be sequential. git gui has the
> same problem, and it's even worse at dealing with it.
>
> as a workaround, i can imagine canceling and re-starting the commit
> whenever the index changes (after a small delay). if the generated
> commit message differs but the user has already edited it, a warning is
> shown (maybe make an exception for the gerrit change-id, otherwise it
> gets annoying; preferentially, the latest generated id should be used to
> minimize the risk of collisions).
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator