Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Feb 3, 2011
  1. Fix: "eval set" called in the wrong context.

    This is the real fix for the incorrect fix that I reverted in the
    previous commit.  parse_cmdline was used to DRY up the source, but this
    introduced a bug because the "eval set" line changes the positional
    parameters semantics, but does it in the wrong context, so the calling
    function never receives the changes.
    This closes at least the GitHub issues #54 and #86.
  2. Don't just take the last argument, take the first.

    This patch was originally contributed as a workaround for the cases
    where there were flags that took the first argument position.  This fix
    was just plain wrong and this commit reverts it.
Commits on Oct 8, 2010
  1. Manually select the last argument.

    This implementation does not rely on Bash-specific functionality.
Commits on Oct 5, 2010
  1. Tidy up a bit.

  2. Added -k option to keep (feature|hotfix|relase) branch when calling '…

    Guillaume-Jean Herbiet authored committed
Commits on Aug 22, 2010
  1. @adamgibbins

    Fixed incorrect color flag

    adamgibbins authored
Commits on Aug 21, 2010
Commits on Jul 21, 2010
  1. Fix whitespace issues.

Commits on Jul 20, 2010
  1. @talios

    Finishing features now only update / and / if they exists, this allow…

    talios authored
    …s you to work on a unpushed repo, or a git svn repo
Commits on Jul 9, 2010
  1. Added new experimental `feature pull` subcommand.

    This new subcommand lets you easily work together with peers on features. It's
    intended to be extremely simple to pull changes from your co-developers.
    This implementation may also be ported to release and/or hotfix branches in the
    near future, if we agree on the final implementation details.
    Example use
    Sharing development of feature branches goes as follows:
    Suppose Alice and Bob are both developers on project Foo.  They have local
    repos that are up-to-date with `origin`.  Then, Alice starts working on some
       alice$ git flow feature start newprotocol
       Switched to a new branch 'feature/newprotocol'
    Then, she hacks on the new feature, commits as desired, until the feature's
    finished.  She then likes Bob to code-review the feature, so she asks Bob to
    pull from her.  (Assuming Bob has a Git remote defined, pointing to Alice's
        bob$ git remote
        bob$ git branch
        * develop
        bob$ git flow feature pull alice newprotocol
        Created local branch feature/newprotocol based on alice's feature/newprotocol.
        bob$ git branch
        * feature/newprotocol
    Since the new feature branch is already checked out, Bob can immediately start
    peer reviewing the code.  He changes the code as desired and commits each
    comment individually, so Alice can later read the Git commit log as the peer
    review log.
        bob$ git commit
        [feature/newprotocol 1f6fa95] Forgot return statement.
         1 files changed, 1 insertions(+), 1 deletions(-)
    When he's finished, he tells Alice he's done.  Alice then, in turn pulls in the
    peer review commits from Bob, using the same command Bob used to fetch the
    changes initially.  (Because feature/newprotocol is still her current branch,
    she may omit the explicit 'newprotocols' argument.)
        alice$ git flow feature pull bob
        Pulled bob's changes into feature/newprotocol.
    If she disagrees with Bob's comments, she may again commit changes and ask Bob
    to do the same again.  This leads to a continuous pull cycle until both parties
    agree on the final implementation.  Then, Alice (as the feature owner) finished
    the feature.  Bob may discard his feature branch.
  2. Forgot to update usage text.

  3. Allow new feature branches in dirty working trees.

    Before this change, `git-flow feature start` would nag about the working
    tree being dirty and disallow continuation. Then, there were two
    - stash away your changes manually, create the new branch, restore the
      stash; or
    - use `git-flow feature start -f` to force creation
    There is absolutely no good reason for git-flow to forbid this creation,
    as git allows it already.  Therefore, the -f behaviour is now the default,
    without an option to turn that behaviour off.  Git takes care of unsafe
    situations again now.
Commits on Jul 8, 2010
  1. Force deletion of the feature branch after finish.

    This fix also works when feature branches are created manually, based on remote
    (i.e. other developers) feature branches, to work on features together.
    `git branch -d` won't remove local feature branches that are set up to track
    remote branches, `-D` will.
    Fixes ticket #31.
Commits on Jun 29, 2010
  1. @Zoramite

    Adding an extra line to the output for extra spacing.

    Zoramite authored committed
  2. @Zoramite

    Adding extra instructions when running the list option without any co…

    Zoramite authored committed
    …rresponding branches found.
Commits on May 27, 2010
  1. Added 'feature checkout' subcommand.

    This can be used as a shortcut to "git checkout feature/full-feature-name".
    Feature branch prefix names may be used for convenience.
Commits on Apr 4, 2010
  1. Fix: unnecessary requirement of origin when creating a new feature br…

    Only test if local branch is behind origin if origin exists.
Commits on Apr 1, 2010
  1. @gmallard
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.
Something went wrong with that request. Please try again.