branchsync seeks to solve a boring but simple problem faced by the working developer.
You write some code on a branch.
You push that branch up to a Git host (GitHub, GitLab, etc.). If you're using GitHub, this means you've reformatted your commit message from being split on 74/80-ish lines because otherwise your newlines get preserved in the HTML that gets outputted because GitHub doesn't follow the spec. (see §6.8 CommonMark)
You create a pull request, merge request or whatever the equivalent is called.
You work on that code some more, and modify the commit message. (You're rebasing and ensuring everything's one commit, right?)
Now your pull request is out-of-sync with the commit message. The single source of truth becomes multiple sources of irritation.
It does this by automating a process that is often done manually by developers,
and then shelling out to the various command line utilities (e.g.
Currently, you'll need to manually compile branchsync. At some point, we can set up CI to cross-compile new releases.
Currently, you just run
branchsync. If there's a problem, it should fail out
with a fairly self-explanatory error.
If you want to see what the code is doing, set the
DEBUG environment variable
to the string 'true'.
The code is not pleasant, it's hacky and built to do the job and no more.
It's Crystal because it is a reasonably nice way to write something high level but also compiles down to a single binary.
There are lots of things to do. For instance:
- CI and cross-compile
- refactor to support multiple providers (e.g. GitLab)
- auto-strip trailers
Signed-off-by(either all of them, or known ones)
- user-specific config stored (preferably in conformity with the XDG spec, preferably TOML?)
- Fork it (https://github.com/tommorris/branchsync/fork)
- Create your feature branch (
git checkout -b my-new-feature)
- Commit your changes (
git commit -am 'Add some feature')
- Push to the branch (
git push origin my-new-feature)
- Create a new Pull Request