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