Re: Working with remotes; cloning remote references

[Michael J Gruber <git@drmicha.warpmail.net>]

Marc Branchaud venit, vidit, dixit 10/21/08 17:17:
> I believe git lets you track the origin's _branches_ not the origin's 
> _remotes_.  I don't think --mirror does what I'm looking for, because 
> (side effects aside) it only deals with branches, not remotes.
> 
> I find myself getting confused, and I think it's because the files in 
> .git/refs/remotes/ are indeed tracking branches on remote repositories. 
>   So I think our conversation gets a bit circular because our ideas of a 
> "remote" differ.

Yes, I think there are multiple uses:

- a remote repository (referenced to by an URL)
- a remote config (as created by git remote add)
- a remote branch (a branch in your local repo which is a copy of a
branch in a remote repo; stored under refs/remotes, never to be modified
locally)
- a (remote) tracking branch (a local branch which is set up to pull
from a remote branch by default)

Only the first of these 4 is something resides "remotely". Of course,
"remote URL" could be a path on the local file system or even ".".

> "git remote add" does two things (maybe more?): It adds a [remote] 
> section to the .git/config file, and it adds a branch reference in 
> .git/refs/remotes/. 

Yes.

> I think what I'd like is for the clone to be able 
> to obtain both these things from the origin.  The reason I think it's 
> useful is that it would let the clone pull directly from the origin's 
> remote repositories, without having to directly specify the remote 
> repository's URL and branch name.
> 
> Fundamentally, I'm looking to do exactly
> 
> 	clone/$ git pull -s subtree /path/to/ThingOne master
> 
> i.e. pull stuff from one of main's remotes directly into the clone.  But 
> I want to replace the "/path/to/ThingOne master" part with something 
> that means "use whatever URL and branch name was defined in the origin 
> for this remote".
> 
> My questions are:  Am I right in thinking this is desirable? 

I've got the strong impression you desire it...

Seriously, it seems desirable in cases where the remote URL changes
frequently; say, because the upstream maintainer (maintainer of
ThingOne) gets hit by a bus frequently, or walks the wrong streets in LA
at the wrong time of the day. (I guess my seriousness ended with the
";".) Clones would follow those changes transparently then (if that
feature existed).

> Is there 
> already some way to do this? 

None that I know of.

> If not, is it something worth 
> implementing?  (I'm happy to roll up my own sleeves here...)

First you should decide whether it is worth for you. Comments on the
list tend to kick in once people see a proposed implementation. A viable
strategy could be, mimicking git submodule behaviour in part:

- Implement "git remote export reponame" which takes an existing remote
config from .git/config, writes it to .gitremotes and checks in (or
better: stages for commit) the file .gitremotes [you would use this on main]

- Implement "git remote import" which reads the file .gitremotes and
adds remote config to .git/config. [you would use this on clones]

- Change "git remote update" to take updates to .gitremotes into account
before doing its usual routine (perhaps based on a config with default
off, or a command line option, or better both)

Downside is that .gitremotes is tracked would show up as a file in the
repo, but I can't come up with a better way which is as simple as the
above. .gitremotes could be stored in a specially named branch, though.

> I hope that clarifies things.  Sorry for taking so long to get here!

Don't worry. I take partial blame ;)
And thanks for trying to match up your workflow with git.

Cheers,
Michael