.git-hooks/prepare-commit-msg

@@ -1,4 +0,0 @@
-#!/bin/sh
-# cc-cli as a commit hook
-exec < /dev/tty
-cargo bin cc-cli "$@"

.gitignore

@@ -4,9 +4,6 @@
 debug/
 target/
 
-# cargo-bin-run cache
-.bin
-
 # Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
 # More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
 Cargo.lock

Cargo.toml

@@ -1,14 +0,0 @@
-[package]
-name = "git-next"
-version = "0.1.0"
-edition = "2021"
-
-# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
-
-[dependencies]
-
-[dev-dependencies]
-cc-cli = "0.1.5"
-
-[package.metadata.bin]
-cc-cli = { version = "0.1" }

README.md

@@ -1,63 +1,3 @@
 # git-next
 
-Automated and minimal merge-queue ideal for a solo developer (later versions may support teams)
-
-Currently this will mostly for myself when working on projects by myself. I'd like to reduce the overhead of PRs, but still maintain CI verification of each commit/patch set.
-
-The `main` branch remains the ready-to-deploy version of the project.
-
-I would then have a `dev` branch where I would do all of my work.
-
-As a commit is added, as long as it matches a conventional commit message and isn't marked as `WIP:`, the `next` branch will advance from the current `main` commit to this next commit where it will be submitted to CI. This may or may not involve a PR. If it passes CI then the `main` branch will fast-forward to that commit (i.e. to `next` which should be a single step). The next commit on the `dev` branch will then be considered.
-
-The application would initially integrate with only with ForegeJo via it's API to interact with the `main`, `next` and `dev` branches and to review the status check results for each commit or PR.
-
-```
-Before:
-*1--*2--*3--*4--*5 main/next
-                 \--*6--*7--*8--*9 dev
-During CI:
-*1--*2--*3--*4--*5 main
-                 \--*6 next
-                     \--*7--*8--*9 dev
-After CI passes for *6:
-*1--*2--*3--*4--*5--*6 main/next
-                     \--*7--*8--*9 dev
-```
-
-The `dev` branch should never need to rebase onto `main` as `main` is only ever advancing along the `dev` branch as each commit passes CI.
-
-### Design
-
-- CLI to initialise the Repo (e.g. create config file)
-- Server that monitors a collection of repos via the Forge APIs
-
-The CLI and the Server could be the same executable taking different commands to decide behaviour.
-
-e.g.
-
-(assuming the command is `git-next`)
-
-Initialise a repo:
-
-```
-$ git next init
-```
-
-This would create a default configuration file: `.git-next.toml`.
-
-Initialise a Server:
-
-```
-$ git next server init
-```
-
-This would create a configuration file `git-next-server.toml` for running the server. It would include details of the repos to be monitored and any credentials to be used.
-
-Start a Server:
-
-```
-$ git next server start
-```
-
-This would start a server using the configuration file in the current directory.
+Automated and minimal merge-queue ideal for a solo developer (later versions may support teams)

justfile

@@ -1,3 +0,0 @@
-install-hooks:
-  @echo "Installing git hooks"
-  git config core.hooksPath .git-hooks

src/main.rs

@@ -1,3 +0,0 @@
-fn main() {
-    println!("Hello, world!");
-}