Re: Working with remotes; cloning remote references

[Marc Branchaud <marcnarc@xiplink.com>]

Michael J Gruber wrote:
> 
> First you should decide whether it is worth for you.

I'm still trying to figure that out...

> 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.

That downside is a bit disappointing.  I might as well just make "git 
remote export" simply generate a script of "git remote add" commands 
based on the contents of .git/config, and check that script in.  Then I 
could run the script in a clone to recreate the origin's remotes.

It also seems awkward to have an export step in the origin repository. 
I don't really see a need for an export step (except as an artifact of 
the above implementation).

It seems to me that this would be more natural if our hypothetical "git 
remote import <X>" could just grab the remotes from repository <X> (or 
the origin, if <X> is unspecified).  I assume that would involve 
lower-level changes than what you described, but to me it seems like the 
more usable approach.  (But then I know nothing of Git's internals, so 
maybe this kind of change would be too much work?)

		Marc