On Sun, Jan 18, 2009 at 22:02, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Sun, 18 Jan 2009, Lars Hjemli wrote: > >> On Sun, Jan 18, 2009 at 19:33, Johannes Schindelin >> <Johannes.Schindelin@xxxxxx> wrote: >> > On Sun, 18 Jan 2009, Lars Hjemli wrote: >> >> Actually, I want this to work for bare repositories by specifying the >> >> submodule odbs in the alternates file. So if the current submodule odb >> >> wasn't found my plan was to check if the commit object was accessible >> >> anyways but don't die() if it wasn't. >> > >> > Please make that an explicit option (cannot think of a good name, though), >> > otherwise I will not be able to use your feature. Making it the default >> > would be inconsistent with the rest of our submodules framework. >> >> Would a test on is_bare_repository() suffice for your use-case? > > No. Inconsistent is inconsistent. > >> If this isn't good enough, how do you propose it be solved? > > As I said, with an extra option that you _have_ to pass when you want > that behavior. My concern is how to discern between wanted and unwanted submodules in a bare repository. With my proposed solution `git archive --submodules HEAD` in a bare repository would only include the content of the submodule repos listed in objects/info/alternates (since the commit referenced by the gitlink would then be reachable). But you mentioned that you had a repository where all the objects of all the submodules where stored in the odb of the superproject. With my solution, `git archive --submodules HEAD` in your (bare) repo would then always include the content of all the submodules (since all the objects would always be reachable), and I believe this is the behavior you don't like. So, would you rather have something like `git archive --submodules=foo --submodules=bar HEAD` to explicitly tell which submodule paths to include in the archive when executed in a bare repo? -- larsh -- 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
