0

As currently I cannot clone repositories from a Bitbucket server, I've found I can still do a series of git init, git remote add etc. to get the repository on my computer. I would like to make sure I exactly produce the equivalent of a "clone". Is the following correct?

git init
git remote add origin -m master https://www.myserver.com/bitbucket/scm/proj/repo.git
# need to do git fetch twice, otherwise for some reason git branch -r 
# returns "warning: ignoring broken ref refs/remotes/origin/HEAD"
git fetch
git fetch
git branch -r
git checkout --track origin/master
git checkout --track origin/develop
git checkout --track origin/feature/myfeature
# (etc.. for all the branches I need to work with)

I'm also not sure about the flag -m in git remote is needed or potentially harmful.

Some debug info as suggested by @jthill :

Repository 1

git ls-remote --symref origin HEAD
ref: refs/heads/master  HEAD
842163b275ade3ec317543ed3a645f537d719766        HEAD

Repository 2

git ls-remote --symref origin HEAD
ref: refs/heads/master  HEAD
1a1044eef2d46a292305dfc10cf076a4cf1e9933        HEAD
Pierpaolo D.
  • 15
  • 7

1 Answers1

1

That's it. The clone is the init, remote add and fetch part, after that you can e.g. git checkout master even before creating the local ref and git will set it up and auto-track the remote because that sequence is so common. The -m just bypasses what that bitbucket repo has as its own main branch and tells the local git what you want as yours, if master is what you want, it's what you want.

So the -m "should", near as I can figure, avoid whatever misconfiguration is going on with the origin's HEAD, and the second fetch "shouldn't" be necessary. If you'll include the results of git ls-remote --symref origin HEAD it'll probably be possible to identify what's causing the trouble, but I don't see much point, you've got a workaround.

jthill
  • 55,082
  • 5
  • 77
  • 137
  • Added that info on the question. Thanks for answering. – Pierpaolo D. Feb 22 '19 at 08:51
  • Okay, there's a lot of interference here, I looked at your other question and something's screwy with that filesystem you're cloning to. The symptom you describe, Git seeming to clone, perfectly normal progress messages, the repo showing up when you ls it while it's running, then after it finishes the repo has vanished, is absurd. This isn't Git doing this to you, this is some automatic filesystem administration tool deciding for whatever reason to move or just delete what you put there. – jthill Feb 22 '19 at 15:13