additional shortcut commands

[erichexter]

I just ran across these additional commands. Is this something you would be interested in having in the project? They seem pretty useful to me.

https://github.com/petervanderdoes/gitflow/wiki/Reference:-git-flow-feature

[jhoerr]

Hi Eric, I believe most of those commands are already supported in the git flow feature scripts. By my read the only one that's missing is git flow feature delete. Is that your observation as well?

[erichexter]

All the full syntax features are present, in particular the following
shorthand commands seem really nice/clean/terse (allow me to be lazy)

git flow finish & git flow publish

Reading thru this doc it seems that those commands determine the correct
argument for (feature,release,support,or hotfix) and Name from the current
branch rather then requiring the full syntax:

git flow feature finish name

allowing you to skip the parts that can be picked up from the current
context of the state of the local git repository(working directory).

Eric Hexter

blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter

On Fri, Feb 27, 2015 at 7:40 AM, John Hoerr notifications@github.com
wrote:

Hi Eric, I believe most of those commands are already supported in the git
flow feature scripts. By my read the only one that's missing is git flow
feature delete. Is that your observation as well?

Reply to this email directly or view it on GitHub
#5 (comment).

[jhoerr]

Ok, I understand you now. As of today you can leave off the branch name and it'll be inferred from the path. But you do have to specify the type of branch -- feature, release, etc.

This appears to be the same behavior that's defined by the spec you referenced. In the interest of maintaining parity with that spec, I'd opt to keep it the current behavior the way it is. I also think it's a good sanity check. I've made enough absentminded bonehead merges that specifying that i'm trying to merge a feature instead of a release seems like a reasonable requirement. (It's like the those flip-up covers that keep you from accidentally pressing the missile launch button .)

Your thoughts?

[erichexter]

You make some very good points about the sanity check.

I did not realize you could leave off the name parameter, that at least
lets you get past the part that is totally variable. I could easily see
my self have multiple windows open each on a different local clone and
accidentally typing finish in the wrong window, because we are madly trying
to get a hotfix our some other urgent release out. Mistakes usually only
happen when you can least afford having them, right?

Eric Hexter

blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter

On Fri, Feb 27, 2015 at 8:48 AM, John Hoerr notifications@github.com
wrote:

Ok, I understand you now. As of today you can leave off the branch name
and it'll be inferred from the path. But you do have to specify the type of
branch -- feature, release, etc.

This appears to be the same behavior that's defined by the spec you
referenced. In the interest of maintaining parity with that spec, I'd opt
to keep it the current behavior the way it is. I also think it's a good
sanity check. I've made enough absentminded bonehead merges that specifying
that i'm trying to merge a feature instead of a release seems like a
reasonable requirement. (It's like the those flip-up covers that keep you
from accidentally pressing the missile launch button .)

Your thoughts?

Reply to this email directly or view it on GitHub
#5 (comment).

[jhoerr]

Alas, when I tried leaving off the branch name, the script returned an error. So it looks like name inference was intended, but not quite implemented.

[erichexter]

I hope my laziness of typing is not rubbing off on you :)

On Monday, March 2, 2015, John Hoerr notifications@github.com wrote:

Alas, when I tried leaving off the branch name, the script returned an
error. So it looks like name inference was intended, but not quite
implemented.

Reply to this email directly or view it on GitHub
#5 (comment).

Eric Hexter

blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter