On 28/06/2021 03:24, Kevin Buckley wrote: > On 2021/06/26 04:48, Philip Oakley wrote: >> >> ... One can also include in the generic 'repository' the >> various special .git* files that are [user] added to the main source >> directory. >> >> But it gets worse. In the .git directory there is the 'objects' ... > > I don't believe it does get worse, indeed, I am not convinced that it > is as bad as your observation on the semantics might suggest. > > Everything within the .git directory "belongs", in my way of thinking, > to the "repository", that is, the directory that gets created when git > is (init)ialised. Part of my view (of the multiplicity of descriptives within Git) regarding what is in a repository is from comparing the git created content from a clone, that of a `git init`, and a users overall project and .git trees after multiple interactions. Each has different features. > > For me, the 'objects", the 'ref/heads', the "staging area' and the like, > also lie within the repository. > > As for any anciliary files, that control how the git commands actually > process any data in the "working directory" beyond the defaults, some > of them, eg the global commands, will typically exist outside of the > working directory: below one's home directory, and, of course, there > are the system-wide files, typically below /etc. > > Given then, that we can have Git-related files, for any given working > directory, below /etc, below the user's home directory, and within the > working directory itself, perhaps it is the whole "computer" which > should be referred to as "the repository"? > > Furthermore, even in the case of anciliary files typically found within > the working directory, and I'm thinking of .gitignore as the obvious > example, even the directives in that can be overriden on the command > line, as well as complemented by files outside of the working directory. > > > I am tempted to say that even if the definition of a "repository" can't > be agreed on, or rather, easily determined by inspection, then at least > the corresponding working directory can be, however, the fact that one > has access to EnvVars and corresponding command line arguments such as > --git-dir=<path>, --work-tree=<path>, would suggest that it could be > harder for the novice to get their head around things, however, as it is > typicaly clear what the working directory is (the top level directory > containing the files you are working on, under the control of Git), > calling that same directory the "repository" seems, to me anyway, to add > to any confusion, that a Git novice may have. > > Given the can of worms that this question has opened up, although I'm > getting the feeling that it has long since been opened, I still maintain > that it would be less confusing, at least for a novice, for the working > directory to be identified and for a previously non-existent directory, > that gets created by the 'git init', to be referred to as the repository, > so as to make a distinction. My main point was that there is this creative tension between the different contexts and that beginners should be aware that it's not all cut and dried in the same way that language definitions tend to be. -- Philip
