Support prepare-commit-msg hooks

[DCVortexxx]

Disclosure

I AGREE TO THE GITUP CONTRIBUTOR LICENSE AGREEMENT.

Full disclosure, this has been drafted by AI because I haven't played with ObjC for yeeeeeaaaaars, but I believe that it respects the coding standard and contribution rules.

Of course, I'm open to suggestions and will happily update it to make it into master.
I LOVE GitUp and having to rely on another editor just because a project I work on needs this hook on it is a pain 😅

Summary

This adds support for Git's prepare-commit-msg hook when creating commits from GitUp.

Git documents prepare-commit-msg as running after the default commit message is prepared and before the editor starts.

To match that lifecycle, GitUp now runs the hook when the commit view prepares the message editor in viewWillAppear :

• The hook runs asynchronously so the commit view remains editable:
  • If the user starts typing before the hook finishes, GitUp preserves their input and inserts the prepared hook output before the user's content.
  • If the hook is still running when the user tries to commit, GitUp prevents the commit and asks the user to wait, since an installed prepare-commit-msg hook should be allowed to finish.

It also runs when the user toggles Amend:

• GitUp first seeds the editor with the HEAD commit message, as it already did before this change.
• It then reruns prepare-commit-msg with Git's amend-style commit source
  • If the message currently shown was only auto-filled by the first prepare-commit-msg run, GitUp replaces it with the amend message flow.
  • If the user has already typed their own content, GitUp preserves it instead of overwriting it.

This also has a side effect on the commit-msg hook, because it used to rely on a app-owned, temporary file for writing the commit message, instead the the $GIT_DIR/COMMIT_EDITMSG file Git uses.
Since prepare-commit-msg relies on this file, commit-msg should read it as well, as the single source of truth for commit message edition.

Note

My first implementation ran it when the user actually commits, right before commit-msg, and it made the code significantly simpler, since we don't need to handle in-flight edit, and "just" update the message in the same way commit-msg does.

However, I changed it to be closer to Git's semantics.
Feel free to let me know if you feel like this is a tradeoff worth having.

[lucasderraugh]

@DCVortexxx Thank you for the candor in using AI. It gives me the appropriate expectation. I assume you've tested locally?

It sounds like a good addition and I will look at the changes soon. This Thursday I'll likely be releasing the 1.5.0 release of GitUp to the stable channel so it won't go in before that.

Probably next week is a realistic time for me to start testing out this change.

[DCVortexxx]

Hey @lucasderraugh, thanks for getting back to me.

Yeah, I tested it locally, through all paths that came to mind :

• Happy path
  • hook runs quickly and updates the commit message when you open the commit view.
• Amend commit
  • hook re-runs with commit argument and the amended commit SHA
• Long hook
  • commit is prevented while the hook is still running.
  • prepared message is inserted above the user input if there were modifications
• Failed hook
  • Error is shown as soon as the hook fails
  • Commit is prevented
    • I wondered if we should allow the user to commit anyway here.
    • The error was already shown once on hook failure, so if the user actually wants to commit, that's up to him.
    • Especially because re-running the hook requires closing and re-opening the commit view, which is probably not that intuitive.
    • Change is trivial, I'll let this product decision up to you
• Multiple hooks:
  • prepare-commit-msg, pre-commit, commit-msg, and post-commit still works
  • They are executed in the correct order
• Merge commit :
  • Started outside GitUp
    • All hooks work correctly, including prepare-commit-msg
  • Started with GitUp GUI
    • The merge message input is generated through a dedicated popup, without going through the commit view.
    • In that scenario, no hooks are executed at all, including prepare-commit-msg.
    • IMO, that's a dedicated fix / feature, not in the scope of this PR

I also have validated that the implementation is reasonable, according to my knowledge of the codebase of course.

Let me know if I can help in any way, and of course, no worries about the timing,
Max

[lucasderraugh]

Wonderful, thank you!