There are some points I disagree with Reply from @Wallacemaxters, as well as the reply from @egomesbrandao also did not please me as a whole. I will give a quick explanation of how the folder and file scheme of a repository works git
and then highlight why @egomesbrandao’s statement is correct and why the @Wallacemaxters solution answers the question.
I’m not gonna stick to repositories either Bare, the reading of the text of the reply should be made with this in mind.
The git
works by identifying files, from the repository root (the location where the directory is located .git
). The identification of a file, however, is not done in the traditional form of conventional file systems, but is more similar to what Amazon uses in S3.
So, to the .gitignore
of the replies of @Wallacemaxters, the git
identifies this file by name /logs/.gitignore
. It is so much so that changes in the position/name of the file git
suggests that you changed the file x
to the archive y
, regardless of the change being just a rename file within the same directory, or have moved to another directory keeping the name, or even name and directory change.
This file identification mode implies that there is no directory concept (within the internal identification of the git
at least). One of the impacts of this is that you don’t have to worry about keeping directories. Move all files from /outer/inner/deep
for /outer/inner
implies that when the next clone
, the briefcase /outer/inner/deep
will not exist. And you did not need to say this explicitly.
The lack of this concept of directories in the git
is the essence of @egomesbrandao’s answer, as well as the origin of one of the original question problems.
The solution proposed by @Wallacemaxters is to make the best use of this mode of operation git
. Internally, folders do not exist. What exists is file identifier with bars in the middle. On the other hand, by "extracting" these files and putting them into the actual file system, directories are created so that the "directory name" is the same as the internal name used by git
.
My point of disagreement with @Wallacemaxters' reply is: when giving git add logs
, you have not added the directory (as this concept does not exist), but ALL the relevant content within the pointed directory. The .gitignore
, in this case, it is a hidden file on Unix file systems, so the impression given is that the directory has been created empty. To maintain the directory structure, any file would be enough. Hidden would be better.
The @Wallacemaxters solution also points to the issue of maintaining empty folder contents logs
in the actual file system (with the exception of .gitignore
, of course). Why the file chosen to "populate" the folder was the .gitignore
, as well as being hidden (ideal to make the directory exist) it also prevents recognition of new files.
In many places it is common to use a file .gitkeep
empty. Unlike the @Wallacemaxters response, the archive .gitkeep
There’s no special interpretation, so there’s no point in putting something inside it. The difference of this alternative is that the directory where it is will not be immediately ignored. This solution has been used in this answer.
Git points to files, not directories, so it won’t be possible to add an empty directory/folder.
– egomesbrandao
In a way, yes, but see another answer where the AR managed to "simulate" empty directory behavior by placing a hidden file
– Jefferson Quesado