Pre checkout hook/event

[KirkEasterson]

Is your feature request related to a problem? Please describe.

I use an auto-session plugin that can create sessions based on the current git branch. I've created an autocommand to load a session when a branch is checked out.

    local neogit_group = vim.api.nvim_create_augroup("UserNeogitEvents", { clear = true })
    vim.api.nvim_create_autocmd({ "User" }, {
      desc = "Load session for checked out branch",
      pattern = "NeogitBranchCheckout",
      group = neogit_group,
      callback = function()
        local neogit = require("neogit")
        local autosession = require("auto-session")

        neogit.close()
        vim.cmd([[%bd!]])
        autosession.RestoreSession("", { show_message = false })
        neogit.open()
      end,
    })

This autocommand is useful for automatically loading sessions. But there exists the problem that the previous session is not saved before switching the branch. I can do this manually with :SessionSave, but I would prefer to have it automated like I have for loading sessions. From my understanding, there is currently no way for me to automate this with neogit.

Describe the solution you'd like

Ideally neogit would allow for some PreCheckoutHook when I can run some lua function. The pros are that it would fix my problem. The cons are that neogit would have a difference between supporting events and custom hooks. This also leads to the question "what other hooks should be supported?" and "should neogit offer both hooks and event?".

Describe alternatives you've considered
Saving the session manually as I described above.

Additional context
I am willing to help contribute to solve my problem and offer more features to other users. But I understand if this feature request would be denied.

[CKolkey]

Hmm... I wouldn't be opposed to having hooks. Maybe the differentiator between hooks and events could be that hooks run before an action (blocking) whereas events trigger after (async)

It doesn't seem too complex to integrate, so I'd be open to a PR :)

[KirkEasterson]

I agree about hooks being blocking vs events being async. I can't think of any scenario where "post action" needs to be blocking. But I am biased with trying to solve my problem vs thinking of what is best for everyone.

I can start by creating a PR for a PreBranchCheckout hook. Once we (and possibly others) are in agreement about how it is handled, then I can work on other hooks. I can imagine that people would want other "pre event" hooks, so it makes sense to create all "pre event" variations. But I'm getting ahead of myself. I'll start with PreBranchCheckout and we can take it from there. Does this sound reasonable?

[CKolkey]

Sounds good. Let's keep the implementation open to extend to other events (pre merge, pre rebase, etc) but as you said - no need to get ahead of ourselves. Solve your problem and let's see where that gets us

[KirkEasterson]

I finally had time this weekend to work on this. I've open a draft PR which you can see above. It would be straight-forward to add more hooks if this is an approach you approve of.