existence of a valid git repo. Instead, functions gitflow_load_settings()
and gitflow_require_git_repo() have been added that can be called in each
submodule that requires such.
Specifically, git-flow init does NOT use this.
them live using git commands instead. This avoids git commands being
issued by subcommands that do not necessarily require an existing Git repo
to be initialized (i.e. git-flow init).
https://wiki.ubuntu.com/DashAsBinSh
Went back from making use of the specific Bourne shell construct 'typeset
-i' for easy integer calculations (typeset -i foo=123; foo=foo+456;) to a
more compatible way (local foo=123; foo=$((foo+456)); )
The 'typeset -f' call has been replaced by a call to 'type', effectively
not testing for existence of a declared *function*, but testing for
existence of a declared *something*. You have to sacrifice sometimes in
order to be more portable.
Require branch and tag to be absent when start is run (for release/hotfix)
Require branch to exist when trying to finish (for release/hotfix)
Die the finish script when either the fetch, checkout or tagging fails.
- Lower-cased all local variable names
- Explicitly typeset all local variable names, to prevent issues with
setting/overriding variables in the global namespace.
- Explicitly typed integer types as integer (typeset -i) to enable simpler
arithmetic calculations on them.
The only exception to the rule is git-flow-support, which has an
explicitly required <base> argument (since we cannot deduce a sane default
name for base).
Furthermore, these <base> arguments are checked to refer to commits on:
- develop (for feature, release)
- master (for hotfix, support)
Removed any occurrences of optional <base> arguments in finish subactions.
The finishing target branches are clearly defined by the model. The <base>
argument will probably confuse users. If they want the power to merge
those feature branches into *other* branches then develop, for example,
they can still use the magical power of Git itself for that. Gitflow
should not provide such support.
Give all the branch-type subcommands a default explicit "list" action, too.
Order the functions inside each of the subcommands in a specific order, for consistency:
- usage()
- setup()
- cmd_default()
- cmd_list()
- cmd_help()
- parse_args()
- other commands
- now works as sub commands to git if copied to $(git --exec-path)
- now works with arbitrary commands for branch types
- consistent variable names
- new branch type 'support' for long-term support branches of historic
versions
- preliminary base branch support for hotfix branch type to create
hotfixes form support branches