Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Feb 24, 2010
Commits on Feb 22, 2010
  1. Better naming of common functions categorizing them into common,

    git specific and git-flow specific functions:
    gitflow_current_branch             -> git_current_branch
    gitflow_is_branch_merged_into      -> git_is_branch_merged_into
    gitflow_local_branch_exists        -> git_local_branch_exists
    gitflow_local_branches             -> git_local_branches
    gitflow_remote_branches            -> git_remote_branches
    gitflow_require_branch             -> require_branch
    gitflow_require_branch_absent      -> require_branch_absent
    gitflow_require_branches_equal     -> require_branches_equal
    gitflow_require_clean_working_tree -> require_clean_working_tree
    gitflow_require_git_repo           -> require_git_repo
    gitflow_require_git_repo           -> require_git_repo
    gitflow_require_initialized        -> require_gitflow_initialized
    gitflow_require_initialized        -> require_gitflow_initialized
    gitflow_require_local_branch       -> require_local_branch
    gitflow_require_remote_branch      -> require_remote_branch
    gitflow_require_tag_absent         -> require_tag_absent
    gitflow_tag_exists                 -> git_tag_exists
    gitflow_test_branches_equal        -> git_compare_branches
    gitflow_test_clean_working_tree    -> git_is_clean_working_tree
    resolve_nameprefix                 -> gitflow_resolve_nameprefix
Commits on Feb 20, 2010
  1. Added function gitflow_require_initialized(), to assert that the gitflow

    variables are all set (they need to be set explicitly once).
  2. Changed GIT_DIR variable into DOT_GIT_DIR, since Git uses it and chok…

    …es if
    the variable is set explicitly by gitflow.
  3. Rewrite the way git-flow initialized its variables in git-flow and as…

    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.
  4. Don't store remote and local branch names in shell variables, but query

    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).
Commits on Feb 15, 2010
  1. Replaced all 'typeset' and 'typeset -i' calls by 'local', as adviced on:

    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.
Commits on Feb 9, 2010
Commits on Feb 7, 2010
Commits on Feb 6, 2010
  1. Tidying up:

    - Move resolve_name_by_prefix() from git-flow-feature to gitflow-common
    - Rename require_name() to require_name_arg()
    - Refactor expanding of nameprefixes
  2. Tidy up:

    - 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.
Commits on Feb 4, 2010
  1. If feature diff is called without arguments, compare the changes made in

    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.
  2. Added an optional <base> argument to all start subactions.

    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.
Commits on Feb 2, 2010
  1. Fix: Of course, in sh, true=0 and false=1. In order to never mess thi…

    …s up
    again, the convenience functions flag() and noflag() have been used and
    all occurrences of 0 and 1 are replaces by true and false. This makes it
    safe (and more readable!) to test for active/inactive flags.
    Also specify $FLAGS_PARENT explicitly, to avoid having the generated usage
    texts by shFlags mention the full Unix path to $0, but instead use the
    more recognizable varient 'git flow feature'.
  2. Fix: do integer comparison, not string comparison. wc returns stuff l…

    …ike ' 13', which is perfectly equal to 13.
  3. Allow for optional <name> argument in feature diffs. (No name uses th…

    …e "current" feature branch.)
Commits on Feb 1, 2010
  1. Implement showing the currently checked out feature branch in feature…

    … list
    overview, very Gitish.
  2. Add initial implementation of the --verbose flag algorithm.

  3. Use shFlags to parse flags given to main and subcommands.

    Implement the flags for each of the 'feature' subcommands.
Commits on Jan 29, 2010
  1. Further divide the parse_args function up, to support automatic prefi…

    …x expansion for all subcommands, except for 'feature start'
  2. Implement the basic logic to resolve name prefixes passed to 'flow fe…

    …ature' into their full feature branch names, if unambiguous.
  3. Support scenarios where the user might have cancelled a merge in the …

    …middle of a merge conflict.
Something went wrong with that request. Please try again.