Russ Allbery wrote: > If you want to do what vcswatch is doing (analyze the current code > repository for Debian packaging for commits that haven't been uploaded), > and the team is, like Haskell, using a single repository for all the > packages, you need to be able to find that specific package in the > repository to look for unreleased changes.
Thanks. Once someone writes some proposed text, it seems like it would be worth mentioning this kind of use case in it. > Similarly, dgit presumably wants to be able to find the part of the > repository that's used for packaging a specific package, and I assume Ian > is thinking about doing some dark magic to make that work with the rest of > dgit's workflow (although I don't know what that is, or how it would work > with, e.g., dgit tagging). *nod* >> And similarly, what is the use case behind the other key/value pairs >> described here? > > We don't know, but we've now had to add two different things we didn't > anticipate, and so it seems like a reasonable assumption there may be > more. For command line options like "-b", I would be okay with following the same model as last time and using space as a source of extensibility (i.e., breaking compatibility). So for that I wouldn't want to use the bracket syntax. For future settings in the same spirit as <path> that don't involve command line options, or for command-line options that are okay to ignore, the Vcs-Git-Whatsit: <whatsit> approach should work okay. So I'm thinking the bracketed path might be enough here, without need for the additional complexity of in-field key/value pairs. [...] > Being able to clone a subdirectory of a Git repository would be lovely, > speaking as someone who works at a company that insists on using a > monorepo. Interesting. That's helpful context. > I think that's a pretty long-standing feature request, though. No one's filed it at bugs.debian.org/git or https://crbug.com/git yet. But there's a similar internal feature request at $DAYJOB. Thanks for indulging my questions. Jonathan
