There are some points I disagree with the @WallaceMaxters answer , as well as reply from @egomesbrandao also did not please me as a whole. I'll give a quick explanation of how the folder and file schema of a git
repository works and then show why the @egomesbrandao statement is correct and why the @WallaceMaxters solution answers the question.
I will also not stick to bare repositories, reading the response text should be done with that in mind.
git
works by identifying files, from the root of the repository (the location where the .git
directory is located). The identification of a file, however, is not made from the traditional form of conventional file systems, but is more similar to what Amazon uses in S3.
Then, for the% w /% of the @WallaceMaxters responses, the .gitignore
identifies this file by the name git
. It is so much that changes in positioning / filename /logs/.gitignore
suggests that you have changed the file git
to file x
, regardless of whether the change was just a rename file within the same directory, or have moved to another directory maintaining the name, or even changing the name and directory.
This mode of file identification implies that there is no directory concept (within the internal ID of y
at least). One of the impacts of this is that you do not have to worry about maintaining the directories. Moving all files from git
to /outer/inner/deep
implies that when the next /outer/inner
is given, the clone
folder will not exist. And you did not have to say it explicitly.
The absence of this concept of directories in /outer/inner/deep
is the essence of @egomesbrandao's response, as it is also the origin of one of the original questions of the question.
The solution proposed by @WallaceMaxters tries to make the most of this git
mode of operation. Internally, folders do not exist. What exists is the handle of the file with bars in the middle. In contrast, by "extracting" these files and placing them in the actual filesystem, directories are created so that the "name with directories" is the same as the internal name used by git
.
My point of disagreement with the @WallaceMaxters answer is: by giving git
, you did not add the directory (since this concept does not exist), but ALL the relevant content within the directory pointed to. The git add logs
, in this case, is a hidden file on Unix file systems, so the impression given is that the directory was created empty. To maintain the directory structure, any file would suffice. Hidden would be better.
The @WallaceMaxters solution also points to the issue of keeping the empty content of the .gitignore
folder in the actual file system (with the exception of logs
, of course). This is why the file chosen to "populate" the folder was .gitignore
, because in addition to being hidden (ideal to make the directory exist) it also prevents the recognition of new files.