> Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > > >> by filling appropriate environ[] array to be run in a repository > >> that is different from ours (which is "other repo" part of its name) > >> not to want to even know which repository the "other" repo is? > > > > Good point. I'll update prepare_other_repo_env() to have a gitdir > > parameter. > > I actually meant that the function should take an in-core "repo" > structure. But that seems like we're passing much more than we need - we only need the git_dir. Also, there is a function that wants to pass a literal "." as the gitdir; if we do this, I'll have to check if there is still a struct repository that we can pass that will result in the same gitdir. > >> Object type and object sizes are something that you can > >> safely express in plain text, would be handy for testing, and would > >> not require too much extra code, I'd imagine. > > > > It would, but we can already use "git cat-file -s" (or -t) for that. The > > helper is meant to test a specific code path wherein we access a > > submodule object during a process running in the superproject. > > I know, but can you use "git cat-file -s" to check the codepath you > care about? I do not think so. Hence the suggestion. I'm still not convinced that we'll need it in the future, but you're right that it is not too much trouble. I'll add it in.
