git flow init fails on cloned repo.

[OJ]

I might be doing this wrong, but if I attempt to clone a repo that only has a develop branch and then try to start a feature using git flow feature start foo then it tells me to re-initialize git flow. Running git flow init fails because the master branch doesn't exist. I have to manually create it for it to work.

This seems wrong to me. Behind the scenes, surely, git flow should either create the required branches or just deal with them not being there. Does this sound like a bug?

Here's a sample session:

oj@mint ~/tmp $ git init test
Initialized empty Git repository in /home/oj/tmp/test/.git/
oj@mint ~/tmp $ cd test
oj@mint ~/tmp/test $ git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
oj@mint ~/tmp/test $ echo "foo" > test.txt
oj@mint ~/tmp/test develop * $ git add test.txt
oj@mint ~/tmp/test develop * $ git commit -m "testing"
[develop 9ebdd64] testing
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 test.txt
oj@mint ~/tmp/test develop $ cd ..
oj@mint ~/tmp $ git clone ./test test2
Cloning into test2...
done.
oj@mint ~/tmp $ cd test2
oj@mint ~/tmp/test2 develop $ git flow feature start foo
fatal: Not a gitflow-enabled repo yet. Please run "git flow init" first.
oj@mint ~/tmp/test2 develop $ git flow init

Which branch should be used for bringing forth production releases?
   - develop
Branch name for production releases: [] master
Local branch 'master' does not exist.
oj@mint ~/tmp/test2 develop $ git branch master
oj@mint ~/tmp/test2 develop $ git flow init

Which branch should be used for bringing forth production releases?
   - develop
   - master
Branch name for production releases: [master] 

Which branch should be used for integration of the "next release"?
   - develop
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
oj@mint ~/tmp/test2 develop $ git flow feature start foo
Switched to a new branch 'feature/foo'

Summary of actions:
- A new branch 'feature/foo' was created, based on 'develop'
- You are now on branch 'feature/foo'

Now, start committing on your feature. When done, use:

     git flow feature finish foo

oj@mint ~/tmp/test2 feature/foo $ 

Thanks!
OJ

[davekapp]

I'm having the exact same problem. I haven't created a master branch locally yet (as that does seem wrong to me as well), but I haven't found a different solution yet. Will post again if I can find something, however.

[OJ]

So far, the only solution I've found is to create the master branch, even if it's not being used. It's not pleasant, but it works. Hopefully there'll be a fix for it soon!

[shuane]

Wouldn't it be wisest to track the initial master branch, e.g.
git checkout -t origin/master

[OJ]

Sure... If there is one! When creating new projects, I don't push an
empty master branch, and after pushing develop, there is no master in
github either.

So its still a problem.

Sent from my Windows Phone (yes you read that correctly) From: shuane
Sent: Saturday, 2 July 2011 6:33
To: oj@buffered.io
Subject: Re: [gitflow] git flow init fails on cloned repo. (#121)
Wouldn't it be wisest to track the initial master branch, e.g.
git checkout -t origin/master

Reply to this email directly or view it on GitHub:
#121 (comment)

[pulkitsinghal]

+1 same issue...

[tmcgilchrist]

+1 same issue

[ansell]

What is the philosophical reason behind not wanting to push the empty initial master branch (that is created by default) when the repository is first created?

If you don't push the master branch (as it seems the commenters here have intentionally not done), then you cannot pull it into a clone. Git-flow is correct in not trying to create a new one, incase you have forgotten to check out a preexisting master branch and would then have a conflict if it created a new branch.

[OJ]

There's nothing philosophical about this. It's to do with workflow. I can push a master branch, but it might not stop people grabbing just the development branch.

Git-flow might be correct in not trying to create a new one. But instead of failing, why not ask me? "Do you want me to create a new branch or shall I track the remote master for you?"

Thoughts?

[ansell]

In the case of some people here there is no remote master because they think it would be wrong to push an empty branch. It would be useful for them to perform

git push --all origin 

to push both the develop and master branches initially to fix that part of the issue.

If there was a remote master it would be useful to ask that question at that point, and shouldn't be too difficult for someone to implement. It is a simple fallback and won't affect anyone elses workflow if they create the master branch themselves.

[lorin]

Here's how we ran into the issue. Most of our development right now in our git repo is on feature branches off of develop.

I had set "develop" as the default branch of the repository on github. I wanted to work on a feature branch of a new machine. I cloned the repo, did "git flow init", and it failed.

[OJ]

@lorin This goes to show there are a stack of ways that we can get bitten by this. Makes a lot of sense to me to have git-flow handle this case, even if it requires an annoying prompt it's still better than not working at all and relying people figuring it out by themselves.

[ansell]

Part of this issue may be that git may only to fetch a single branch when you run git clone, and if you set the GitHub default branch to be something other than master, as I do myself as well, then master will not be there as a remote reference until you run git fetch origin (I think). If that is the case for many people, the commit that added the change for git-flow-init to support checking for remotes/origin/master [1] may need to be extended to add a "git fetch origin" call before checking whether the master exists.

[1] baf163e

[baby-gnu]

then master will not be there as a remote reference until you run git fetch origin (I think).

The git clone operation literally clone the repository as noted in the progit boot, you can disconnect your network wire and do:

git checkout -b master origin/master

git will create you the local branch called master as a copy of origin/master.

[kasterma]

Note:

git checkout master

is sufficient as if the branch is not found but there is a tracking branch that one is used.

[michaellenahan]

@kasterma thank you!

$ git flow init

Which branch should be used for bringing forth production releases?
   - develop
Branch name for production releases: [] 
Local branch '' does not exist.

$ git branch -a
* develop
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/master

To get the local branch:

$ git checkout master
$ git checkout develop
$ git branch -a
* develop
  master
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/master

Now run git flow init as normal.

$ git flow init

[SgtPooki]

git config gitflow.branch.master master to set your master branch properly when you cannot "cancel" a git flow init.

[simonweil]

Same here, I have the same issue.

[Tapefabrik]

+1 same issue

[shan-lyons]

+1

[chrisRidgers]

Just ran into this. Garrrgh! +1

[rob-moore]

Make sure to checkout master at least once on your local repo.

[CocoFox]

I will thanks

On Nov 18, 2016 6:41 PM, "Rob Moore" notifications@github.com wrote:

Make sure to checkout master at least once on your local repo.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#121 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AVuyNjaPvHr8jyO9Zmy1bzynI0mhm0F_ks5q_eNRgaJpZM4AD0E_
.

[yylian]

+1 Happened to me too.

[bipinct]

did following steps to fix the issue on cloned repo

 git checkout -b master
 git checkout develop
 git flow init

[tvkit]

My TeamCity CI process can wrap a build within a git flow release via ant scripts, but I learned along the way that it was necessary to checkout both master and develop, and then run the default initialization prior to the build:

git flow init -d

[karsilama]

Wouldn't it be wisest to track the initial master branch, e.g.
git checkout -t origin/master

works for me! thank you

[andres310597]

The solution is:
-git ckeckout master
-git checkout develop
-git flow init

[mjstelly]

@andres310597 That may be the answer for you. It did not help on my repo.

➜  mobile_provider git:(develop) git checkout master   
Updating files: 100% (17199/17199), done.
Switched to branch 'master'
Your branch is up to date with 'origin/master'. 
➜  mobile_provider git:(master) ✗ git checkout develop
Updating files: 100% (17199/17199), done.
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.                                                            /3.1s
➜  mobile_provider git:(develop) git flow init       

Which branch should be used for integration of the "next release"?
   - bug/mstelly/prov/2449-leave-job-crash
   - master
   - poc/realmdb
Branch name for "next release" development: [develop]

And my .gitconfig file contains no reference to any flow setting. So I don't know where the values are being stored.

[mjstelly]

The fact that this issue has remained open for 9 years says a lot about our chances that it'll get resolved any time soon. However, I accepted the defaults and received this message:
To force reinitialization, use: git flow init -f
So, it's not broken. I guess it's not well documented. Someone should probably close this issue.