Commit message generation via LLM/CLI

[iest]

Hey all,

I forked the repo and added a feature that generates a commit message for currently staged files using codex-cli:

You can see the commit for this here:

iest@f49640a

The idea would be to make the CLI call user configurable, so users could plug in Ollama or llm or whatever tool they wanted that would return a commit message when given a diff. We'd also want to make the commit prompt user configurable so users could customise whatever formatting they wanted.

Is there an appetite for this sort of feature? I'm sure the current implementation is not fit for production release but I'm sure it could be made so.

If this is the wrong place for this sort of discussion, please feel free to close, I won't be offended.

---

p.s. Much respect to all the contributors to this fine application! It's been my git app of choice for I guess 10 years now... keep up the great work 🙌

[lucasderraugh]

Very neat!

I don't have any strong things to say, but more of some guidelines perhaps (my brain dump if you will).
I think LLM features are something that should always be optional and I don't want to force the UI to get in the way of the core functionality. One thing I'm always weary about in the app is adding buttons or unnecessary chrome. I'm not sure if a button along the bottom is the right place, but perhaps it could live in a menu bar item or maybe it's a suggestion inline in the text view if you haven't typed anything and have content in the index. I don't have a great UI take on this yet.

The other thing, which you alluded to in your comment above, is that any LLM based features should be completely configurable such that we don't want to tie the users to any particular model. My only exception to that would be if it utilizes Apple's Foundation models.

I consider the LLM features that would plugin to any 3rd party service (aka not Apple's) to be it's own feature set. We probably would want some tab in settings to be able to explain and configure these things. Maybe relying on defining the command line to run through NSTask is enough, but we'd need some way to persist this information.

Sorry for the ramble. I'm busy trying to get the Tahoe release out soon so I can't think about this all too much but I appreciate the experimentation and if you want to start a discussion on how there may be some kind of plugin architecture to standardize on, that would be fine. I would be more keen on trying Apple's Foundation models first before trying to setup an entire infrastructure for 3rd parties, but again, my time is limited.

[iest]

Appreciate the brain dump!

I had a lot of the same thoughts, including the same UI idea of having a small button inside the text input (rather than additional chrome) but went with the simplest option for now.

100% agreed this should be optional (and opt-in), and totally user configurable. In my current implementation the shell command is stored in UserDefaults, the user can enter whatever they want, including variable replacement for $PROMPT and $DIFF. That way they can plug in their own API keys or whatever for whichever service they want to use:

Then we'd also want the prompt to be configurable (I currently stole Zed's one for the same feature they have).

In terms of plugins, my experience so far in various apps with these sorts of features is that the configuration is always a huge pain: local or cloud hosted models, hardcoded to certain providers, then having to pass in API keys to do HTTP calls... whereas the beauty of the CLI is offloading all that complexity elsewhere (so they can hook in whatever tooling they want). I would guess that any GitUp users who would want this kind of feature would have the technical knowhow to set this up correctly.

Afaik apple foundation models don't have a CLI, so we'd need native integration, not NSTask. Perhaps we could default to Foundation with an option for raw CLI commands for advanced users?
I would presume that building in support for plugins for various 3rd parties would be a lot of work by comparison. Also so far Apple's Foundation models have been quite disappointing...

Anyways, appreciate your time & thoughts on this. I'm happy to continue hacking on this and discussing further. I can report back with plugging in Foundation models as the default option?

[lucasderraugh]

Ya, the CLI configuration approach is probably at most what we'd want to support for now. I don't want to get into managing API keys just yet. Apple's Foundation models are weak at the moment, though I haven't tried them for this task and I expect those to be acceptable come the next OS release. There is no CLI for those, but it would be great to hook into that API to give the user a no-setup option. Ideally we can define some protocol that both the CLI and other vendors (e.g. Apple's Foundation models) can communicate through. I know we have technical users (it is git after all) but the goal is obviously to make it simple for GitUp.