Hi,
Tomas Carnecky wrote:
> The ref is first stored
> as 'impure', meaning that it doesn't have any representation within git. Only
> after the remote helper fetches that version into git, it can tell us which
> git object (SHA1) that revision maps to.
Hmm.
The existing ls-remote output looks something like
<object id> HEAD
<object id> <refname>
<object id> <refname>
...
<object id> <tag refname>
<object id> <tag refname>^{}
...
In particular, each line has a 40-character object id, a tab character,
and then something like a refname.
If we want to extend that, wouldn't we need to do something like
0000...0000 <refname>
0000...0000 <refname> is r11
to avoid breaking people's scripts? For example, I wouldn't be surprised
if scripts are relying on the following two properties:
- each object id is 40 characters (e.g., the old fetch--tool
in contrib/examples relies on this)
- each object id contains no whitespace
simply because they are convenient to script with.
--
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