git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Working with remotes; cloning remote references

From
Marc Branchaud <marcnarc@xiplink.com>
Date
Oct 27, 2008, 19:54 UTC
Message-ID
<49061C6D.2070407@xiplink.com>
In-Reply-To
<48FF3FEE.8020209@drmicha.warpmail.net>
Michael J Gruber wrote:
> 
> First you should decide whether it is worth for you.
I'm still trying to figure that out...
Show 18 quoted lines
> 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
Previous: Björn SteinbrinkNext: Michael J Gruber
Message 22 of 24 in “Working with remotes; cloning remote references”
  1. Marc BranchaudOct 16, 2008
  2. Peter HarrisOct 16, 2008
  3. Marc BranchaudOct 16, 2008
  4. Peter HarrisOct 16, 2008
  5. Marc BranchaudOct 16, 2008
  6. Michael J GruberOct 17, 2008
  7. Marc BranchaudOct 17, 2008
  8. Michael J GruberOct 17, 2008
  9. Marc BranchaudOct 17, 2008
  10. Michael J GruberOct 20, 2008
  11. Marc BranchaudOct 20, 2008
  12. Michael J GruberOct 21, 2008
  13. Marc BranchaudOct 21, 2008
  14. Michael J GruberOct 22, 2008
  15. Terminology question: "tracking" branchesBjörn Steinbrink, Oct 22, 2008
  16. Michael J GruberOct 23, 2008
  17. Marc BranchaudOct 27, 2008
  18. Björn SteinbrinkOct 27, 2008
  19. Johannes SchindelinOct 27, 2008
  20. Björn SteinbrinkOct 27, 2008
  21. Björn SteinbrinkOct 28, 2008
  22. Marc BranchaudOct 27, 2008
  23. Michael J GruberOct 28, 2008
  24. Marc BranchaudOct 28, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.