Bug#932696: Please document Haskell team style Vcs-Git sytax
Jonathan Nieder <jrnieder@gmail.com> writes:
> In Git, when you "git clone" a repository, that represents a single
> codebase. There is no parameter you can pass to "git clone" that
> tells it to clone just a subdirectory. So we aren't including the
> <path> in Vcs-Git in order to determine what parameters to pass to
> "git clone".
> Given that, what *are* we including the <path> for?
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.
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).
> 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.
> It's possible that it might make sense to use separate fields for this
> information --- e.g. a
> Vcs-Git-Path: <path>
> or something like that. That way, you get extensibility for free.
This is definitely true, and if I were paying more attention when this
first came up and had thought of it, I'd probably recommend that. But I
think the water is already under the bridge since the bracket syntax is
already being used, and I'm not sure it's worth asking them to change
something that's already implemented in at least a couple of places.
> Alternatively, maybe there is a lurking Git feature request here, for
> example for an atomic view across multiple repositories, or for the
> ability to clone just a subdirectory of a repository (with
> https://crbug.com/git/2 you already almost have that, though it's fussy
> to set up sparse checkout to do it and you still have to "cd" into the
> subdirectory).
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. I think that's a pretty long-standing feature request, though.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: