Luke Diamand <luke@xxxxxxxxxxx> writes: >> What I am trying to get at is if we want to use a single command >> that can be given a path and answer "Yes, that is a repository" >> here, and that single command should know how the repository should >> look like. I offhand do not know we already have such a command we >> can use, e.g. "git rev-parse --is-git-dir $path", but if there isn't >> perhaps we would want one, so that not just "git p4" but other >> scripted Porcelains can make use of it? > > That would be nicer than random ad-hoc rules, certainly. I couldn't > find any obvious combination that would work. I've already sent an update but my reading of this code is that there is no need for the program to be able to, given a random directory path, ask isValidGitDir() "is this a Git repository?" at all. What the program wanted to know, IIUC, is "Where is the 'Git repository directory', if there is one?". This is needed primarily because the program wants to error out before doing any operation that requires a Git repository to work on, when the answer is "there is none". It also wants to know it because (for whatever reason) it wants to export it in GIT_DIR [*1*]. And isValidGitDir() is a helper function used by the handcrafted logic in main() to answer that question, but as far as I can tell, you'd get a more correct answer by asking "rev-parse --git-dir" unconditionally (even when the user of the program exported GIT_DIR to you). I just was reading Lars's LFS changes, but that one has hardcoded "Is there a '.git/lfs/objects/' directory directly inside the current working directory?" and similar, which I do not think would work well in a secondary working tree where ".git" is merely a file [*2*]. In a "secondary working tree"-aware world, I think you would need to ask locations of --git-dir and --git-common-dir to rev-parse upfront and choose which ones are ought to be shared entities across the family of worktrees and which ones are to be private per worktree. I suspect that LFS objects want to be shared across working trees that share the object store, for example, which would mean that "--git-dir" is not what Lars would want to use. [Footnote] *1* I do not think this is necessary. Git tools know how to find the repository by first checking GIT_DIR environment and if it is not set then by walking up the directory hierarchy just fine without the program exporting GIT_DIR for them. *2* The part that bases this path relative to getcwd() is OK, as the start-up sequence in main() does a cdup to the top before everything else.