After doing 'commit --amend' or 'rebase -i develop' on a feature branch and then running 'git wize-flow publish' we get a message that we cannot push feature branch to origin. A 'git wize-flow publish --force' option is needed.

There's a lot of code duplication on integration tests for feature/bugfix/hotfix/release workflows since the vast majority of the process step s are the same. Refactoring the test suite to avoid repeated code would make the code more maintainable and will also potentially increase test suite speed.

Currently Python 2.7+ is required to parse the JSON from Hub client raw api calls. This is not a MUST-have dependency since its contribution on the CLI is minimal and is easily replaceable with a lighter dependency such as https://stedolan.github.io/jq.

Bashcov should report the accurate test coverage report for both integration and unit test suites. Update the README file before closing this issue.

Currently, when doing a manual installation all wize-flow scripts are available under PATH. Only the main driver git-wize-flow should be under PATH.

Having two separate scripts for install / uninstall makes no sense. We need a single script 'install.sh' that can have receive both 'install' and 'uninstall' arguments.

When tracking a long-living upstream branch, running 'git push' should fail. A test case to show this behavior to tests/git-pre-push-hook.bats and add the required functionality to src/common/pre-push-script (if applicable)

When a repository is being re-initialized with 'git wize-flow init' command, we expect that the old gitflow.* configuration values are removed. This is not the case.

Currently, for some input validations, it is a requirement to have a wize-flow repository enabled. This doesn't make sense. All basic input validation should happen before the script validates whether or not the current directory is a wize-flow enabled repository.

For more information, see the TOFIX note on tests/git-wize-flow.bats

This issue requires functionality described on 42

Currently, the install and uninstall script tests are disabled because wize-flow installation directory cannot be changed. After issue 42 is done, enable those tests and add robustness.

For more information, see tests/git-wize-flow-install.bats and tests/git-wize-flow-uninstall.bats TODO notes.

The CLI when running 'git wize-flow finish' from hotfix or release branches is currently setting the tag message value to the tag itself. This should not happen.

When working on a release or hotfix branch that's already ready to be finished and running 'git wize-flow finish x.x.x', the program ignores the specified name and sets the tag name incorrectly.

Before closing this issue, enable the test cases on tests/git-wize-flow.bats to verify that the input validation is successful

Running 'git wize-flow init' should work no matter the state of the git repository to be initialized. Several more tests are needed to verify this functionality.
Also, running 'git wize-flow remove' should work only on wize-flow enabled repositories.

Missing test cases:

1. Running 'git wize-flow init' without arguments in an already initialized repository should fail

2. Running 'git wize-flow init' on an existing directory with git initialized without a remote configured and without git-flow initialization should execute successfully

3. Running 'git wize-flow init' on an existing directory with git initialized with a remote configured and without git-flow initialization should execute successfully

4. Running 'git wize-flow init' on an existing directory with git initialized with a remote configured and git-flow initialized and without wize-flow should execute successfully

5. Running 'git wize-flow remove' on an un-initialized repository should fail

6. Running 'git wize-flow remove' on a wize-flow initialized repository should pass

We need to avoid hardcoding the version software inside the script itself. The version number should be taken from src//version file in order to externalize this value.

Currently wize-flow is installed at /usr/local/opt/wize-flow by default and there's no way to change the installation location. Adding this functionality is crucial to implement installation/de-installation tests without recurring to symlinks or hacky workarounds.

Currently, when running 'git wize-flow' to show usage, it is not clear which arguments are required and which ones are optional under which circumstances. A clear git-like usage is needed to let the users know how to run the CLI commands.

Currently, integration tests running concurrently from different clients will experience undefined behavior (since two test suites running on different machines will affect each other). The wize-flow-test repository needs to handle tests running in parallel.

Currently, the repository de-initialization (removal) stage is leaving the git wize-flow specific configuration on the git repository. The expected behavior is that the de-initialization process also removes al wize-flow specific values from .git/config file.

On current CI process shellcheck is run with "--exclude=SC2143,SC2004,SC2236" option. BASH source code needs to be modified so no warnings or errors are thrown by removing those excluded rules.

Currently, the installation on different Linux distros is completely manual and adhoc. If wize-flow installation script could support bpkg it would make installation consistent and at the same time, simply the installation flow.

When initializing an existing repository with 'git wize-flow init', the process will override any existing configuration. The expected behavior is that any existing pre-push script contents are preserved.

Currently, wize-flow rules are "hardcoded" to be able to work with Wizeline's GitFlow process. This is done by configuring git-flow in a deterministic way using git-flow-defaults.sh file and also the branch names are fixed on wize-flow-setup.sh init function.

It would be great if wize-flow could work with any git-flow configurations transparently without the need to override existing configuration.

Currently, conflicts caused in automated merges have undefined behavior (most likely a git conflict message will appear or the call will fail altogether). The correct behavior for this case needs to be defined.

1. Refactor common functionality and repeated code.
2. Modularize the code into distinct components (as much as possible).
3. Avoid long lines and complex one liners. Make them descriptive or add comments.

Currently, running integration test suite takes way too much time because the following things happen on almost every test case:

1. wize-flow is being "installed" (copied to a known location)
2. git repository is being initialized with wize-flow

Also, on feature/bugfix/hotfix/release workflow tests there's a lot of code repetition which greatly affect the total testing time

Besides those, I am sure there are more optimizations that can be made.

Currently, the only way to add new code changes to an existing wize-flow enabled repository is to do the following process:

1. De-initialize the repository with 'git wize-flow remove'
2. Uninstall CLI by running de-installation script
3. Install updated CLI
4. Initialize repository with 'git wize-flow init'

Users should not be able to run more than 1 git wize-flow command to achieve this functionality. One proposed approach is to run a 'git wize-flow update' that pull latest version and does everything transparently.

Bugfix and Feature branches can branch for other feature or release branches, not only from develop. Therefore, the CLI needs to find the origin base branch and support merging back to those.

Currently Ubuntu and related Linux distros are supported by relying on Linuxbrew and some apt-get commands for Linuxbrew dependencies. Linuxbrew and all its dependencies should not be required to run wize-flow on those systems.

If one of the following commands are interrupted, they can leave either the installation directory or the repository in an inconsistent state:

1. wize-flow-install.sh
2. wize-flow-uninstall.sh
3. 'git wize-flow init'
4. 'git wize-flow remove'

Make sure all these stages handle unexpected interruptions gracefully

Joker implementation should be removed from the official release in order to avoid confusion due to multiple CLI versions

Currently, BASH unit tests are disabled for tests/git-pre-push-hook.bats. There should be a way to test this functionality with unit tests