On Thu, Aug 18, 2016 at 11:46 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jacob Keller <jacob.e.keller@xxxxxxxxx> writes: > >> From: Jacob Keller <jacob.keller@xxxxxxxxx> >> >> Currently, do_submodule_path relies on read_gitfile, which will die() if >> it can't read from the specified gitfile. Unfortunately, this means that >> do_submodule_path will not work when given the path to a submodule which >> is checked out directly, such as a newly added submodule which you >> cloned and then "git submodule add". > > Hmm, are you sure about that? > > A call to read_gitfile() turns into a call to read_gitfile_gently() > with the return_error_code parameter set to NULL. The function does > a stat(2), and if the given path is not a file (e.g. we created the > submodule working tree and repository in-place ourselves, instead of > cloning an existing project from elsewhere, in which case we would > see a directory there), it says READ_GIT_FILE_ERR_NOT_A_FILE and > returns NULL, because that is not a fatal error condition. The same > thing happens if path does not yet exist. > > This caller is given <path>, prepares "<path>/.git" in buf, and > calls read_gitfile(). If it returns a non-NULL, it replaces what is > in buf and continues, but if it returns a NULL (i.e. the two cases I > mentioned in the above paragraph), it continues with "<path>/.git". > > While I do not think changing it to resolve_gitdir() is wrong per-se, > I am not sure if it is necessary. > > I must be misreading something in the existing code. > No I think you're correct. I was under the assumption that it would die here. I think it's probably better to stick with read_gitfile() here, it should work. The main issue is what happens after this needs to be fixed. I'll investigate this more. Thanks, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html