Hey @rahulk94 i think its absolutely awesome that there are still people actively using this! First, thanks for making my Monday 👌🏻. Second, to answer your question, we could, theres a pretty in-progress branch trying to migrate the project to typescript, but ultimately have been just lacking the time to finish it. If anything, I would prefer that new features are introduced post migration, but there aren't any solid dates for that.

This had come up in the past but it was pushed off as kind of out of scope, and I wanted to just keep this simple, but there's probably a way to keep true to "check it out" and allow for more custom actions to be made as well

Hey @jwu910 yeah I saw the TS migration going on.

I've got a branch here off of master which feels simple to me since there's only one new git operation added main...rahulk94:check-it-out:add-delete-feature and then everything else uses the existing functions.

Let me know if you'd like me to tidy it up (branch name and what not) and open a PR.

Also I'll take a look at the TS rework going on and see if I can be of any help OR contribute the feature to both branches (with a TS version for the TS branch ofcourse).

@rahulk94 the ts migration just got merged into main today, latest should be up and running. Just wanted to let you know.

If there's any support we can provide, pls let us know. thanks!

Hey @jwu910 thanks for the update. Cool I’ll rebase and add some typing and open a PR for this some time this week.

Hey @jwu910 I've opened #541 now to add support for this 🙂 let me know in the PR if you need anything extra from me

Thanks again for the patience, coming back to this as @a-camarillo was joining me as a maintainer here, wanted to have a discussion on this. I think being able to delete branches with CIO is awesome but my mixed feelings is based on some pretty superficial details. Im only hesitant becuase I called this project "check it out" and now doing way more than checking out a branch as a mutable action with our project refs feels a little bit more "not what i would expect" when using this tool.

However, that being said, i'm in favor of extensibility and preferable to that. I think a cool middle ground to let users still potentially want to delete selected ref from CIO, could be to look at a custom command we can bind to maybe one or two keys...

I was talking with @a-camarillo the other day and was thinking through a couple low-change solutions that keeps freedom/creativity in the users hands, while keeping the responsibility of just displaying project refs in the realm of CIO.

One potential route could be to have a custom button print the ref to stdout so users could pipe CIO into another process they've either written themselves, or some other tool they may be using.

Another would be to follow a similar pattern to the extraRefArgs or gitLogArguments that we're currently using w/i the Configtore and use the custom hotkey approach to pass the current ref into this custom command the user can define w/i their ~/.config/configstore/check-it-out.json after installing this.

I think these approaches could still allow for users(and yourself) to achieve a deletion of the current ref, with a very intentional approach, while not straying too far away from my original intention of this project

Thoughts?

@jwu910 feel free to copy whatever you need from jack-cli's command framework. Allowing users to define their own commands can replace a multitude of feature requests!

I can't take this on myself now but I'll be happy to advise/consult anytime.

Happy to hear from you @drewbrokke, thanks, I don't have the bandwidth to personally work on this at the moment either, so hoping to create the discussion and see if the current PR against this issue would pivot to address the outcome of this--or maybe something else.

Thanks for responding @drewbrokke, I can likely work on this. It looks like jack-cli utilizes a json file for custom user commands, is that correct?

Correct, it's part of the config json file

Ok, yeah that's definitely a route I had in mind. I'd like to leave it open to discussion before deciding to work on the feature.