To develop that project and run tests locally, it is needed to have Python installed with tox
.
Use tox -e venv
to setup virtual environment to work on that project in your favorite IDE.
Use .tox/venv/bin/python
as a reference python
interpreter in your IDE.
To run tests, execute tox
.
Run docs/setup-sandbox
script to set up a test repo under ~/machete-sandbox
with a remote in ~/machete-sandbox-remote
.
Deprecated commands are excluded.
Property | Commands |
---|---|
can accept interactive input on stdin | add , advance , delete-unmanaged , discover , go , traverse , update |
can display status (and run machete-status-branch hook) |
discover , status , traverse |
can modify the .git/machete file | add , advance , anno , discover , edit , slide-out , traverse |
can modify the git repository (excluding .git/machete) | add , advance , delete-unmanaged , go , reapply , slide-out , squash , traverse , update |
can run merge | advance (*), slide-out , traverse , update |
can run rebase (and run machete-pre-rebase hook) |
reapply (**), slide-out , traverse , update |
can slide out a branch (and run machete-post-slide-out hook) |
advance , slide-out , traverse |
expects no ongoing rebase/merge/cherry-pick/revert/am | advance , go , reapply , slide-out , squash , traverse , update |
has stable output format across minor versions (plumbing command) | file , fork-point (***), is-managed , list , show , version |
(*) advance
can only run fast-forward merge (git merge --ff-only
).
(**) reapply
can run rebase but can't run merge since merging a branch with its own fork point is a no-op and generally doesn't make much sense.
(***) A stable output is only guaranteed for fork-point
when invoked without any option or only with --inferred
option.
This tool is semantically versioned with respect to all of the following:
- Python and Git version compatibility
- command-line interface (commands and their options)
- format of its specific files (currently just
machete
file within git directory) - hooks and their interface
- output format of plumbing commands (see above for the list).
Output format of any non-plumbing command can change in non-backward-compatible manner even between patch-level updates.
-
Merge the changes from
develop
tomaster
and pushmaster
. -
Verify that the release has been created on Github and that a
git-machete-<VERSION>-1.noarch.rpm
file is present under the Assets. -
Verify that the latest version is uploaded to PyPI.
-
Verify that a version-bump PRs to NixOS/nixpkgs has been opened.
-
Verify that the latest commit in VirtusLab/homebrew-git-machete tap repo refers to the latest version.
-
Verify that a build started for Snap. If not, check
build.snapcraft.io
webhook on Github (under Settings > Webhooks) - sometimes the Snap Store's build system responds with 500 status for no clear reason, in such caseRedeliver
the call.Once ready, install the
latest/edge
revision locally (sudo snap install --edge --classic git-machete
) and verify that it works correctly, esp. wrt. push/pull via ssh/https and editor (git machete edit
and interactive rebases).Then, perform a release from
latest/edge
tolatest/stable
for bothi386
andamd64
from Snapcraft web dashboard or via CLI. -
Verify that a build started on git-machete PPA.
Once the new version of package is published and the old one is removed (typically takes around 20-30 min), follow the instructions from ci/deb-ppa-test-install/README.md. Inspect the output of
docker-compose
and verify that the latest version gets correctly installed on Ubuntu (esp. see the output ofgit machete --version
). -
Thanks to the courtesy of Ilaï Deutel, a git-machete package is hosted in Arch User Repository (AUR). If the release introduces significant changes/critical bugfixes, please flag the package as out of date.
-
Verify if changes you made in blog-1.md and blog-2.md are reflected in corresponding medium articles: Make your way through the git (rebase) jungle with Git Machete or Git Machete Strikes again!. If not please apply changes also here to keep consistency.