What is the flag bare

very short wording

here you need to, say, copy the archive from one server to another, and you are given instructions:

1. copy the archive from server1 to the local machine
2. unpack the archive
3. copy the archive to server2

why, one wonders, point 2 is needed here, about unpacking the archive ??? not needed. Here is a similar situation when copying a repository - but why extract the contents of the working directory from the repository? not necessary. this is --bare option --bare .

more detailed answer

perhaps we should start with an illustration of what, in fact, is git-storage (the term “git-repository” is often used).

here it is, the newly created repository, which does not track (yet) a single file, but already contains 9 directories and 13 files (in different versions and builds of the git program, specific numbers may, of course, be slightly different), the minimum that will allow the git program to start tracking files of your project (well, almost necessary - you could do without examples files from the hooks directory):

 $ tree -F . ├── branches/ ├── config* ├── description ├── HEAD ├── hooks/ │  ├── applypatch-msg.sample* │  ├── commit-msg.sample* │  ├── post-update.sample* │  ├── pre-applypatch.sample* │  ├── pre-commit.sample* │  ├── prepare-commit-msg.sample* │  ├── pre-push.sample* │  ├── pre-rebase.sample* │  └── update.sample* ├── info/ │  └── exclude ├── objects/ │  ├── info/ │  └── pack/ └── refs/ ├── heads/ └── tags/ 9 directories, 13 files 

these files and directories will appear in the current (initially empty) directory after executing the command:

 $ git init --bare 

and if you omit the --bare option, they will all be “hidden under the hood” - the git program will create them not in the current directory, but in the .git subdirectory (the dot at the beginning of the name serves to ensure that in the unix-like operating system default was not shown when getting listing directory).

“Hidden” they will not only be “for aesthetics” and not only because these “internal guts” are of little interest to the “ordinary” user of the git program. The main goal is to “release” the current directory under the actual files (and directories) of your project. in this case, it (the current directory) will perform the functions of the working directory ( working tree in the original documentation, another often encountered translation - a working copy ).

if the repository has a working directory , then this repository is called “non-bare-repository”, or “repository with a working directory”, and more often, for brevity, simply “repository”. and if there is no working directory , then such storage is called “bare-storage” (literally “bare”).

and what is the use of such "bare-storage"? what is the practical meaning of it? what can we do with him?

Well, from the point of view of the “end” user (most often the programmer) there is really little use, because the project’s files / directories are not visible. but from the point of view of the program git is a full-fledged repository that can be cloned, made of it pull-s , and push-s into it. It is in this form (without a working directory ) that the storages are located on such servers as github.com, bitbucket.org and the like. The git program can easily extract and display any information from such a repository: the history of commits, the listing of project files, the contents of any of the project files in the state it looked like after any of the commits, and so on and so forth.

The --bare option can --bare be used with the clone command: in this case, the backbone of the repository (consisting of the above 13 files and 9 directories) will be created in the current (or specified) directory, which will be filled with information from cloned storage (basically it will touch the objects directory - it is where git-objects are stored: commits, trees and blobs).

but if you execute the clone command without this option, then, firstly, the storage will be placed in the .git subdirectory, and not directly into the current directory, and secondly, after filling the storage, all project files and directories will be additionally extracted into the current directory .

It is worth noting that the storage attribute “bare / non-bare” is stored in the config file inside the storage as the line bare=true or bare=false in the [core] section.

ah, yes, I completely forgot:

What does it (implied option --bare ) gives when migrating the repository ?

from the above, I hope it became clear that this option, in the case of transferring storage from one server to another, makes it possible not to do unnecessary (in this case) work: save processor cycles (retrieving project files / directories), save hard drive resources on unnecessary read operations / records, save some electricity, and, eventually, postpone the thermal death of the universe. this is the real purpose of human existence, right?