that case, don't check if the working tree is clean (this yields errors in
HEADless repos).

This fix enabled users to use "git init && git flow init", too.

variables are all set (they need to be set explicitly once).

fully initialized for use with gitflow.

Add a means of only asking for the missing gitflow definitions, not all.
(Of course, redefining all is always possible using the -f (--force) flag
of init.)

(dash), since the empty string '' means "take the default suggestion"
already. Only needed in rare cases.

conventions, too.

initialization and a more user-friendly (and more comprehensable) way of
asking the user which branches are the master/develop branch.

environment/branches.

Added test for existence of local branches.

-a" returns remote branches with a "remotes/" prefix. "git branch -r"
still returns branch names we are used to.

the variable is set explicitly by gitflow.

They are required. Their existence tells us that this repository is
gitflow-enabled.

Added some TODO notes to implement.

branches should be used for master and develop and then initializes the Git
repo itself and/or the git-flow branches for him or her.

git branch.

Added gitflow_branch_exists() function for testing existence.

Let gitflow_test_branches_equal() return with exit code 4 in case of the two
branches having no common ancestor.

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).

still exists one.

should come *after* the redirection of stdout to /dev/null. For an
explanation and a simple demonstration of the differences, see:

	http://is.gd/8srJR

    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.

release/hotfix branch fails finishing, the user may just try so again.

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.

- Move resolve_name_by_prefix() from git-flow-feature to gitflow-common
- Rename require_name() to require_name_arg()
- Refactor expanding of nameprefixes

- 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.

Renamed shFlags.sh -> gitflow-shFlags

this feature branch *including* the changes in the current working tree.

If an explicit feature branch is named (may be a prefix of a branch name),
the diff shows only changes that are already committed.

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.