Cookie Engineer's Website

Git EVAC

Git EVAC Teaser

Overview

Git EVAC is my experimental repository management tool. Its purpose is to fix, pull, push, and manage all local repositories as automated as possible, without having to intervene actively.

But, as git isn't a failsafe, the restrictions are tailored to my personal workflow. If you have a different workflow, you have to either use strictly my triangular workflow with feature branches or look for a different tool.

This is also the first tool that I built with the Gooey Framework which is quite unique, as it's the only Web Components framework made for the wasm target platform of Go . The software is therefore completely written in Go , HTML , and CSS . All frontend code is implemented with gooey's component framework. The native app itself embeds all web assets and bundles a webview which points to the local webserver.

Workflow

The proposed git workflow is a strict triangular workflow.

  • Least common denominator action precedes. #1
  • No rebases allowed that could lose references to master branch.
  • No shallow clones, use your gogs or gitea instance for that.
  • All Users and Organizations can be hosted on multiple remotes. #2
  • All remotes must use the same branch name schemas.
  • The origin remote must be the source of truth for merge conflicts. #3
  • The folder structure is ~/Software/<organization or user>/<repository>/.git .

[1]: If one of the selected repositories requires a fix for a detached HEAD because of a merge conflict, you have to do that one first. If you have an uncommited change, you have to commit. Only clean work trees can be pushed and pulled to/from remotes.

[2]: Remote name conventions are github , gitlab , gogs , or gitea . API endpoints are currently unsupported, but will be hopefully supported to get an overview of available repositories; so that batch cloning them locally can be automated, too.

[3]: If there is no origin remote, you have to fix that.

Actions

As the strict triangular workflow is enforced, work on downstream forks has to be done in either feature-specific branches or on the master branch directly. Git EVAC assumes that local repositories are always in a clean state before the push and pull actions, which implies that no uncommited changes to the work tree are allowed.

All actions are batchable, meaning that they can be applied to multiple selected repositories in a queued manner once confirmed in a preceding overview dialog.

  1. The Fix action precedes all others, and is displayed for a merge conflict , detached HEAD or otherwise unmergeable changes where the index differs too much from the work tree .
  2. The Commit action is displayed when the index differs from work tree and uncommited local changes exist.
  3. The Pull action pulls changes from all remotes, and assumes that the current branch is in a clean state. After the initial fetch it will attempt to diff against origin/<branch> to figure out whether a git merge origin/<branch> is possible.
  4. The Push action pushes changes to all remotes, and assumes that the current branch is in a clean and merged state.
  5. The Backup action exports a repository into a backup folder that will store the compressed file as ~/Backup/<organization or user>/<repository>.tar.gz file.
  6. The Restore action imports a repository from a backup folder's compressed file into the ~/Software/<organization or user>/<repository> repository. If that repository already exists, it is renamed to <repository>.bak to prevent loss of changes.

Building

The build process is fully integrated with the Go build toolchain. All of the software's dependencies are automatically downloaded and compiled if necessary.

# install go toolchain
sudo pacman -S go;

# build wasm frontend app and webview native app
cd /path/to/git-evac;
bash build.sh;
						

Usage

If you start the git-evac program, it will automatically open a WebView UI that guides you through the setup process. The default view will show the state of all git repositories located in the ~/Software folder.