Add new feature subcommand called "clone/update" #29

nvie opened this Issue Jul 6, 2010 · 5 comments

2 participants


Quick braindump

Its purpose is much like "tracking" a remote peer's feature, to work on it together and share commits, passing by the origin repo until it's finished.

git flow feature clone <remote> <name>

For example, Alice has a feature called "refactoring" and wants Bob to run a peer review on it. Then, Bob fetches Alice's branches (given he has read access in Alice's repo). He receives a remote branch now called "alice/feature/refactoring". To do this, he calls:

git flow feature clone alice refactoring

he should get a local branch called feature/refactoring, that is based on alice/feature/refactoring, but is not tracking that in the Git sense (because a subsequent git push will not have commit access to Alice's repo and will therefore fail). The clone action:

  • fetches Alice's branches (git fetch alice)
  • creates a local feature branch based on Alice's feature branch if that feature branch does not exist locally; or
  • merges Alice's branch into the already existing local feature branch
  • checks out that new branch

Then Bob commits his peer review comments and tells Alice to fetch again. Alice does the same thing on the other side, then:

git flow feature clone bob refactoring

Implementation detail

If we add an optional flag to this command called --track, we can replace the git flow feature track <name> subcommand implementation by a call to git flow feature clone --track origin <name>.


I'm not quite happy with the name of the subcommand yet. To avoid confusion with the git clone behaviour, I think the final name should be something different. Maybe something more general like "update"? Also I think it would be nice to make no distinction between the situation where the local feature branch does not yet exist (i.e. "branch"-like) and the situation where it does already exist and you want to update (i.e. "pull") Alice's (or a third person's) changes in again.


What happens when it isn't a feature? What if it was a code review for a hotfix, etc? Or if the remote repository uses a different prefix for their development?


Well, the subcommand could analogously be added to the other commands, too. It is indeed quite useful to be able to share release/hotfix branches among developers.

I think we can safely assume that the remote is using the same prefix for feature branches. Providing the flexibility to use different remote naming styles does not outweigh the complexity it requires in my opinion.


That makes sense. I was thinking that you could use a --prefix featurette style when you are tracking/cloning the feature.

I'm a bit ignorant of what it would take to accomplish the task but it seems you could store the prefix information with the rest of the tracking information for the branch.


Maybe "pull" would be a better name for the feature?


Initial implementation in f68d405. See commit message for details and example usage.

@gmallard gmallard pushed a commit that referenced this issue May 13, 2011
@nvie Tell getopt to parse POSIX compatible.
By setting the environmental variable POSIXLY_CORRECT, getopt behaves
strictly POSIX-compatible.  This fixes the incorrect getopt parsing
style that breaks git-flow in several flavours of Linux.

Many thanks to Thiana for figuring this one out.

This should fix issues #28 and #29.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment