[EMAIL PROTECTED] (Eric W. Biederman) writes:
> The big question is in what format should we return the heads?
> Just a space separated list of sha1's or a directory hierarchy
> like git-clone-pack uses.
My knee-jerk reaction is something like this:
$ git-list-remote jg-libata
9956d54ace3c64512d0c5498e0137180741e5d04 heads/adma
433e7832818faf93c0f366fea3e14773cdcf3811 heads/adma-mwi
...
80ebd62e0cca50869da2d5159fa4d6b723f0c014 heads/sil24
9e734775f7c22d2f89943ad6c745571f1930105f tags/v2.6.12-rc2
26791a8bcf0e6d33f43aef7682bdb555236d56de tags/v2.6.12
...
a339981ec18d304f9efeb9ccf01b1f04302edf32 tags/v2.6.13-rc3
That is, SHA1 and path relative to .git/refs separated with a
TAB, and terminated with LF.
I do not care too much about the protocol level, but since we
are not talking about hundreds of heads and tags, probably
the simplest would be to match the same, or use SP instead of
TAB there to match upload-pack protocol.
I think the bigger question is how to help the user manage and
store this information in his .git/refs/tags hierarchy.
The mechanism to store the URL and head in branches/<name>, and
copy the head value in the corresponding refs/heads/<name> was
borrowed from Cogito, and I think it covers the refs/heads side
quite well. The user gives a name to the branch of a foreign
repository he is interested in, the fetched head from there is
stored in the same <name>, so the namespace under refs/heads and
branches are totally under the user's control.
If somebody cares about automated fetching of all the tags from
a remote repository, probably the easiest way would be to create
a subdirectory that corresponds to the short-hand name and use
that directory to store all tags slurped from there. But I am
not convinced myself this is that much useful.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
