Less typing [feature] about gitflow HOT 10 CLOSED

Actually, I'm also looking for a clean, yet simple, solution to prevent you from typing a lot of words to perform such a simple task.

I don't think dropping flow would be a real option though, since then you would have to create first-class Git subcommands called git-start and git-finish, which would be too general and meaningless for someone who first encounters those.

But I agree that typing git flow start feature xxx (5 words!) is not very Git-like.

Effectively, what we're currently doing is:

• git flow list feature
• git flow start feature xxx
• git flow finish feature xxx

A better approach would be to mimicking Git's default behaviour of the git-remote subcommand by flipping the "start" and "feature" arguments:

• git flow feature (like git remote)
• git flow feature start xxx (like git remote add xxx)
• git flow feature finish xxx (like git remote rm xxx)

An alternative way would be to mimic Git's default behaviour for the git-branch subcommand:

• git flow feature (again, like git branch)
• git flow feature xxx (like git branch xxx)
• git flow feature --finish xxx (like git branch -d xxx, but this one really itches me somehow)

Also, a downside to that approach is that we will have trouble bringing the other feature branch actions (track & publish) under this subcommand structure.

If you insist on dropping the "flow" command in your personal environment, you could easily create an alias for that:

git config alias.feature='flow feature'

Or, replace git flow by flow by creating a shell-level alias:

alias flow='git flow'

But those are just personal optimisations for power users. I strongly feel that we should keep all specific stuff for the branching model support collected under one git-flow umbrella.

from gitflow.

Thinking of it, my personal favourite would be to use the git-remote style subcommands. You have the subcommands ordered to form a logical hierarchy:

git flow feature action args

1. git: it's git after all
2. flow: it's about the specific workflow
3. feature: do something with the branch type "feature"
4. action: do this action to this branch type
5. args: optional arguments

Those who want to type less can then easily set up either git or shell aliases for that. We can even recommend this in the README file.

I don't feel that the git-flow command itself should be responsible for providing short commands, merely to provide a logical ordering of those commands that is easy to grasp and accomplishes a better design.

Linus already provided the goodies for power users through git aliases for that exact purpose, after all.

from gitflow.

please see my branch, i have reordered the command line

from gitflow.

Well, it seems that we have been working on the same issue here :)
It's too late right now, so I'll have a look at the most suitable implementation tomorrow. Although we use slightly different names, the general solution seems pretty similar at first sight.

Cheers ;)

from gitflow.

yeah, we should maybe open an irc channel or something ;)

from gitflow.

Most definitely! It's kinda cool that we came up with such similar solutions. Must be a good sign.

from gitflow.

channel #gitflow on freenode or you can also contact me via xmpp at [email protected]

from gitflow.

Thanks nvie & hollow. The project so far is awesome. Thanks. :-)

You make good points. Power users can use aliasing to shorten a lot.

I'm already using

start  = 'flow start'
finish = 'flow finish'

Most git commands follow the pattern git-verb, with git-remote being on of the few exceptions. IMHO, it feels more natural to specify 'start' or 'finish' before the type (i.e. feature/hotfix/release).

Would it be possible to omit the type from finish commands? It seems that finish can inspect branch name to determine if it's a feature, hotfix, or release.

from gitflow.

Couldn't it just autodetect what you're trying to think of, with a little work? E.g., a feature feature/themes could be finished with:

git flow finish themes

If there is more than one branch type with the same name (E.g. support/themes and feature/themes), you can then warn that the name is ambiguous and require the type to also be specified:

git flow feature finish themes

This can also apply to hotfixes and releases, too. The only problem is that when starting new features / supports / hotfixes / releases, the type would have to be specified. This could be at least lessened by the user using one letter aliases for types:

git flow f start themes
git flow s start docs
git flow h start theme-fix
git flow r start v1.0

These are just some of the ideas I came up with when reading this issue. Additionally, then when just running git flow <type>, then it would just list the current branches for that type (like git branch).

Edit: It seems I didn't read the OP very well. This is just my spin on the idea then.

from gitflow.

I think sthrs has a pretty good point. Having git-flow guess the branch type upon finishing is a good thing to have. In practice, I believe there will almost never be any ambiguity (and if there is, we can take care of it).

The lot-of-typing subcommand structure of git-flow is something I've been wrestling with since the beginning of the project, but I'm starting to feel more and more for a structure that does not specify the "feature/hotfix/release/support" intermediate subcommand.

Instead, we could have something like ktheory already proposed in the original issue: to start a new feature branch, simply type:

git flow start foo
git flow start -r 1.3

And finish off with:

git flow finish 1.3  (it will know it's about the release branch)
git flow finish foo  (it will know it's about the feature branch)

Also, all other commands can profit from this intelligence:

git flow checkout 1.3
git flow checkout foo

However, implementing this in shell scripting really requires a big effort in rewriting, due to the subcommand structure breakdown that is currently active. Additionally, such a big refactor of the source code is not something I'd be pretty happy about without having unit tests lying around. Therefore, I want to propose to do this as part of the Python-rewrite (see issue 33). This will enable more flexibility in the subcommand structure. Lastly, we could even keep the current feature/hotfix/release/support subcommand structure as a means of staying backward compatible.

Let me know what you think about this.

from gitflow.