Oops, not fix in release 1.12.0.

I think I'll just need to rebase onto the latest version. I can probably do that later today.

Having the same problem.

Same issue here, our auto updates process failed because of these default being gone.

FWIW: Workaround. If you need the previous defaults, a way to set those would be:

git config gitflow.prefix.hotfix "hotfix/"
git config gitflow.prefix.feature "feature/"
git config gitflow.prefix.bugfix "bugfix/"
git config gitflow.prefix.release "release/"
git config gitflow.prefix.support "support/"

I just ran into this issue when trying to teach a new guy on our team about git-flow :)

I just looked at that PR and it looks good. Anything you need more from the community?

Git for Windows 2.21.0 has been released two days ago and it contains git-flow v1.12.0. That means that this bug now affects a lot more users.

The bug also affects the manual git flow init (without the -d parameter). Output is the same as shown in the initial comment of this issue.

@petervanderdoes Any chance to get this fix in a bugfix release? Waiting another one or two years for the next feature release of git-flow wouldn't be a good way to handle this.

Just released 1.12.1 which should take care of the issue

Wait, did you close my MR instead of merging it? Seems a bit harsh

I also wrote this on @adamrodger 's github page, and he commented "For what it's worth, I also reviewed the merged changes and I still think my implementation is clearer and neater":

My apologies @adamrodger I saw an email when I got to work and quickly made some changes without checking if there were PR's or not.

I will add your name to the changelog.

I just checked your code and wanted to comment on my implementation compared to yours.

My thought process is that if you use a parameter you explicitly tell the software that the given name is the name you want. In your implementation it still checks if there is a setting in a configuration somewhere and that would take precedent over the parameter.

Our shop has been a GIT FLOW shop for over 5 years - long time use - and this bug is driving us crazy. PLEASE FIX THIS - the git flow init -d has always provided the default prefixes - if very few newbies do not want the defaults as its always been -that is on them - but PLEASE GET THIS FIXED. This problem is still in 2.21 as of April 19, 2019 (the latest version available). If few want blank prefix defaults - then give them another default like -db.

Still not fixed in 1.12.2 AVH Edition!!

Edit:
Wait. Now it is working. The problem is now that repos with already empty prefixes in the local config doesn't get the basic prefixes when using git flow init -df.

@petervanderdoes - see the comment from @hylke94 above. This is why my MR used the precedence order that it did. The new precedence order causes the problem above.

You can set a default prefix value global or system wide as well.

This means that if you set a global master branch prefix as foo and the repository is not initialized yet it will suggest the prefix to be foo for the master branch. That's the reason the precedence order you suggest won't work @adamrodger

I can see the issue as described by @hylke94 Hopefully I can find some time today to address this issue and release a new version.

Hopefully this is fixed with the 1.12.3 release

I will try it tomorrow evening (if Manjaro sees the new release this time directly ;)). Tonight I'm busy.

Requested an update of this package on the aur package repository. Guess I need to wait a little longer...

Confirmed that it works! Even empty prefixes are reset correctly again 👍

Hi all,
I am on windows, with a not really upgradeable git/flow.
For me this quick-init works, and is ^c^v-able well..
Hopefully we'll get a fixed version soon! (:
(in the repo, in a shell: )

git flow init -fd ;\
git config --worktree gitflow.branch.master "master" ;\
git config --worktree gitflow.branch.develop "develop" ;\
git config --worktree gitflow.prefix.hotfix "hotfix/" ;\
git config --worktree gitflow.prefix.feature "feature/" ;\
git config --worktree gitflow.prefix.bugfix "bugfix/" ;\
git config --worktree gitflow.prefix.release "release/" ;\
git config --worktree gitflow.prefix.support "support/"

You just need to pull the master and develop branches on your local repo. Always works for me.