-1

The git Atlassian tutorial's git clone page provides the following info for the git clone --bare command:

... In addition, no remote branches for the repo will be configured with the -bare repository.

  1. What does this mean?
  2. Does 'remote branches' refer to the original repo or the cloned repo?
Liam
  • 27,717
  • 28
  • 128
  • 190
SSteven
  • 733
  • 5
  • 17
  • 3
    https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---bare – Liam Oct 13 '21 at 16:05
  • @Liam, thanks for the link. I had already seen it. It states 'When this option is used, neither remote-tracking branches nor the related configuration variables are created.' What are remote-tracking branches? – SSteven Oct 13 '21 at 16:08
  • Your real question, per comment, seems not to be so much what `--bare` itself does, but rather about what Git calls *remote-tracking branch names*. It would be better to ask that. There are actually many SO questions and answers that involve this, but unfortunately standard Git terminology here is ... obnoxious? poor? I'm not sure what adjective to use. The problem is that the phrase *remote-tracking branch name* is just a very bad name for this thing, whatever one wishes to call it. – torek Oct 13 '21 at 18:08
  • I tend to use the phrase "remote-tracking name", which at least avoids the already-badly-overloaded Git term *branch*. It's still not a great term. [This answer](https://stackoverflow.com/a/1070851/1256452) from 2009 helps explain what the thing itself is *about:* regardless of what we call it, its purpose is to remember some *other* Git repository's branch names. – torek Oct 13 '21 at 18:10
  • 2
    The thing you have to get first—the fundamental issue, as it were—is that to Git, *branch names don't matter*. Git provides them for humans, but doesn't really need them itself. What Git needs are raw commit hash IDs. These are pretty useless for humans, though. So, Git provides *names* for these hash IDs. There are multiple forms of names. – torek Oct 13 '21 at 18:13
  • 1
    When you make a clone of some repository, you make a new Git repository. This new Git repository gets copies of all of their (the other Git repo's) *commits*. But you get *your own branch names*. So your Git, making your new clone, has to do ... *something* ... with their branch names. Throwing them away entirely is unfriendly, so the "something" is to copy *their* names to what Git calls *remote-tracking branch names*, where the word "branch" is misleading. – torek Oct 13 '21 at 18:14
  • @torek, thanks for your comments, which have demystified the issue. Also, I have corrected the title. – SSteven Oct 14 '21 at 06:18
  • *the word "branch" is misleading* **Full stop**. A branch I think was taken from older SCM like SVN, etc. Where you actually branched the code into totally different container in the repo. Git doesn't do this because it's inefficient and causes merge hell when you try and remerge the branch in. So in git a "branch" isn't a physical thing, It's simply a **pointer** (maybe they should be called pointers but I think that horse has bolted) on the git **graph** which is where the commits actually reside. – Liam Oct 14 '21 at 11:08

1 Answers1

1

--bare Make a bare Git repository. That is, instead of creating and placing the administrative files in /.git, make the itself the $GIT_DIR. This obviously implies the --no-checkout because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created. Git-clone

Irakli Shalamberidze
  • 302
  • 3
  • 11