remote ref namespaces

[jherland]

The remote ref namespace idea has been around for a couple of years, and would e.g. help solve the problem of easily pushing/pulling git-notes between repo. But the idea has not yet materialized into working code. I'm trying to do something about that, but there are open questions that would benefit from being discussed by more Git developers.

What are remote ref namespaces

This is basically about changing the default refspecs that git uses when setting up a new remote (including the origin remote set up by "clone"), and also associated changes to make things more streamlined with the new set of refspecs.

Today, the default refspecs are:

[remote "eggs"]
    fetch = +refs/heads/*:refs/remotes/eggs/*
    url = ...

which places the remote-tracking branches from eggs into refs/remotes/eggs/. The tags from eggs are implicitly fetched by the default tag auto-following behavior of Git, and are placed directly into your local tag namespace refs/tags/. Other kinds of refs (e.g. notes, replace refs, etc.) are not fetched at all, and the user is left to make up custom ref hierarchies and corresponding custom refspecs to fetch them from one repo to another.

Remote ref namespaces would instead have the default configuration for a new remote look something like this:

[remote "eggs"]
    fetch = +refs/heads/*:refs/remotes/eggs/heads/*
    fetch = +refs/tags/*:refs/remotes/eggs/tags/*
    fetch = +refs/notes/*:refs/remotes/eggs/notes/*
    ...
    tagopt = "--no-tags"
    url = ...

First, we make everything more explicit by disabling the implicit auto-following, and instead fetch the tags with an explicit refspec. Next, we construct a ref hierarchy under refs/remotes/eggs/ that mirrors the top-level refs/ hierarchy. By moving the remote-tracking branches from refs/remotes/eggs/* to refs/remotes/eggs/heads/*, we carve out space for other types of remote-tracking refs to co-exist. This means we can now keep the tags fetched from the remote repo separate from our own local tags. It also means that we suddenly have a natural place to store remote-tracking notes, or any other kind of (future) remote-tracking reference.

See http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885 for the initial proposal and following discussion. See my recent postings to the git mailing list for current progress.

What needs to be discussed?

Here are some of the open questions that have popped up in the course of starting to implement this idea:

• Do we try to design Git to work well with the new refspecs specifically, or do we try to make Git work well with whatever crazy refspecs the user might throw at it?
• Today, $remote/$branch (e.g. origin/master) is a much-used shorthand that is automatically expanded to refs/remotes/$remote/$branch by Git prepending refs/remotes/ to the shorthand. Do we still want to keep the $remote/$branch notation working with the new refspecs, or do we want to force users into using $remote/heads/$branch instead?
• If we want to keep $remote/$branch working, by what mechanism does the expansion happen? Do we simply insert a set of hardcoded strings between $remote and $branch (e.g. "heads", "tags") until we get a match, or do we "go the long route" by looking at what actual remote-tracking branch would result from fetching $branch from $remote (i.e. mapping through the configured refspec)?
• git branch -r lists remote-tracking branches. What should it list? Do we define a remote-tracking branch according to its refname matching some specific pattern, or do we use the refspecs to look at where the remote-tracking branches are actually placed by git fetch?
• How do we deal with remote-tracking tags? Should they be listed by git tag -l? Do we need a new git tag -r for listing remote-tracking tags?

I'm sure there are more things I haven't thought of yet, that might come up as part of the discussion.

[mhagger]

+1. I have a special place in my heart for Git references.

[jherland]

A couple of more questions open for discussion:

• Do we need/want to place the remote ref namespaces outside refs/remotes? (Alternatives mentioned so far include refs/peers/* and refs/track/*.)
• As the expansion of $remote/$branch gets more complicated, we may have to restrict the format of remote names to not include the / character (so that we can unambiguously split between $remote and $branch on the first /). This means that we are in effect disallowing multi-level remote names. Is anybody not OK with this?