Git EVAC
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
masterbranch. - 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
originremote 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.
- The
Fixaction precedes all others, and is displayed for amerge conflict,detached HEADor otherwise unmergeable changes where theindexdiffers too much from thework tree. - The
Commitaction is displayed when theindexdiffers fromwork treeand uncommited local changes exist. - The
Pullaction pulls changes from all remotes, and assumes that the current branch is in a clean state. After the initialfetchit will attempt todiffagainstorigin/<branch>to figure out whether agit merge origin/<branch>is possible. - The
Pushaction pushes changes to all remotes, and assumes that the current branch is in a clean and merged state. - The
Backupaction exports a repository into a backup folder that will store the compressed file as~/Backup/<organization or user>/<repository>.tar.gzfile. - The
Restoreaction 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>.bakto 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.