Allow finishes to optionally keep the feature branch pointers hanging around about gitflow HOT 19 CLOSED

Hello, I've forked the gitflow repo and added this feature under a feature/keep-branches branch. For this to work, I had to fix the parse_args() function in several files.

Please refer to http://github.com/gjherbiet/gitflow/tree/feature/keep-branches for review and possible integration.

Thanks,

-Guillaume

from gitflow.

Hi Guillaume,
I've cherry-picked your commit onto my develop branch, it's in 8fee0c2 now. Thanks for your contribution!

from gitflow.

Thanks, I also made a branch with this modifications but starting from the 0.3 release, as I was experiencing issues #28 and #39 when using the develop branch (on Mac OS X 10.6.4 with bash 4.1.7(2)-release).

So here's the branch with the "-k" option on top of 0.3 : http://github.com/gjherbiet/gitflow/tree/feature/keep-branches-0.3

I've also created a 0.3.1 tag with this option (this is the version I now use and that works -so far- on my system): http://github.com/gjherbiet/gitflow/tree/0.3.1

When I have time, I'll try to investigate why this bug is appearing between 0.3 and develop version (but that not a promise...).

Regards,

-G

from gitflow.

I don't understand that remark. The patch is quite simple and does not cause any problems here. This will be included in the future 0.4 version, which will be released when there is "enough new stuff" on develop.

from gitflow.

Ok, it's just that when I switched to using the develop branch for git flow, I face issues #28 and #39. So reverting to 0.3 and adding the "-k" option on top of it was a quick (maybe dirty) way to get that working on my system.

from gitflow.

So you are saying that issue #28 does not apply to 0.3 of git-flow? Interesting... must look into that tonight.

from gitflow.

At least this is what I experience on my system.

from gitflow.

I'm not sure if this counts as a bug or not.... Given [git flow feature finish -k newfeature], flags complains about -k being an unknown option. However if you do [git flow -- feature finish -k newfeature] it works correctly. Basically the -k is seen as an option to git-flow, not git-flow-feature. This is the reason for issue#28 as well.

from gitflow.

Hi Thiana,

I've just tried using git flow feature finish -k newfeature on the git-flow version on which I have added this function on release 0.3 (see gjherbiet/gitflow@8a8087d) and it went just fine.

Could you tell me which version you are using, and if this persists when you use the release 0.3.2 I pointed you to.

Regards,

-Guillaume

from gitflow.

The problem also occurs with gjherbiet/gitflow@8a8087d... And I am using 47d1b9d.

from gitflow.

nbowe/gitflow@2ad7fc07bf6f9a776834 allows git flow feaure finish -k newfeature to parse correctly. The problem with the other versions is that FLAGS doesnt know about the options for git-flow's subcommands. Which leaves the question of why your version doesn't see the -k as an option to git-flow itself. Could it be a difference in the way git/1.7.1 is passing the commands to git-flow perhaps? Which version of git are you using?

from gitflow.

Hi Thiana,

That's some great insight into the root cause of this bug. It seems that, on some platforms, the getopt utility (or the platform specific implementation of shFlags) will treat flags as though they were given to the git-flow top-level command. Only a solution remains now...

Which platform/OS are you using, btw?

Cheers,
Vincent

from gitflow.

Hi,

It is also possible that some versions of getopt silently ignore anything that looks like a flag if it's not in the shFlag generated option list. What happens when you run /usr/bin/getopt -o h -l help -- --help -k (assuming getopt is in /usr/bin)? Here it causes an invalid option error.

I'm running linux(debian) with getopt(enhanced)/1.1.4.

-- Thiana

from gitflow.

My version getopt (default one under Mac OS X 10.6.4) yields -- h -l help -- --help -k. I've heard this is a (rather old) BSD version. So maybe the problem comes from discrepancies between versions. We really need that Python-based implementation to solve such problems... :-)

from gitflow.

Yes, indeed, getopt does accept this string on Mac OS X. Do you use -l to specify "long" arguments to getopt? Long opts are not supported on Mac OS X's getopt, namely. See this example output:

$ /usr/bin/getopt -o h -l help -- --help -k
-- h -l help -- --help -k

As you can see, it strips off the -o param, since Mac OS X's getopt expects the first argument to be the pattern specfication. Maybe this makes the example a bit clearer:

$ /usr/bin/getopt h -h                 # (1)
 -h --
$ /usr/bin/getopt h finish -l -k foo   # (2)
 -- finish -l -k foo
$ /usr/bin/getopt lk -l -k foo         # (3)
 -l -k -- foo

This is how git-flow/shFlags works under the hood. The main git-flow script declared a -h flag to getopt, but the first non-flag match declares the start of the argument list, considering any remaining "flag-like" strings that follow it as arguments, too. This shows from (2). That output then is processed further. The first argument ("finish") is interpreted as the "subcommand to run", which then invokes git-flow-finish, accordingly. That script sets up another getopt parser that parses optional flags -l and -k, as shown in (3).

If platform-specific implementations of getopt don't allow (2), git-flow will fail.

from gitflow.

It looks like there is a simple solution (no changes to shFlags). If you export POSIXLY_CORRECT=1 before any option processing is done, the linux getopt acts like your mac version (ie, passes -k through without generating a warning).

from gitflow.

Wow, that would be really cool. Are you able to patch git-flow locally and test it? Otherwise, I'll see if I can do this myself this evening.

It should be put before this line, where shFlags is sourced and set up: http://github.com/nvie/gitflow/blob/develop/git-flow#L71

from gitflow.

Already tried and tested it. It works perfectly now :)

-- Thiana

from gitflow.

Fixed in e1ec57d and tagged in 0.4. Many, many thanks, Thiana!

from gitflow.