On Fri, 17 Nov 2006 00:41:33 -0800, Junio C Hamano wrote: > I have no objection to this if it is done in a controlled way > that does not make life more difficult for people who work with > multiple remote repositories. That's fine with me. Maybe I didn't explain this well before, but my desire is exactly for this to work with multiple repositories. Specifically, what we have in cairo is a "central" shared tree that many people push to. But we only have two branches there, (one for bug-fixes only for our stable releases, and one for ongoing development of new features, and that only of stuff that's well cooked). So that tree looks and acts an awful lot like our cvs tree back in the past. It's often very linear and often fairly boring to look at in gitk. Meanwhile, all the really interesting stuff happens in personal repositories where people have their own branches for stuff that is still getting cooked. This is what's a lot more fun to watch, and there's a lot more distributed back-and-forth that goes on here as people collaborate on things. And it's all this kind of collaboration that cvs never helped with at all, but git has been great. So, what I want is both "git update" for the central tree. I said we only have two branches, but that's really only two that are active---the "stable" branch is actually a new branch after every major release. It was 1.0 for a while, is 1.2 now, and will be 1.4 later. So I want "git update" to automatically pick those new branches up as they get created. Meanwhile, I also want to use "git update" to track everything that people are working on in the more wild personal trees. So, yes, I do want "git update" to be able to track lots of remote repositories in a sane way. What I have been doing up to this point is a little script I wrote that does git-ls-remote on the repository I want to track and writes a .git/remotes file to bring in all their branches. So if I want to see what behdad is up to, I first refresh his .git/remotes file with my: cairo-git-setup-remotes behdad then: git fetch behdad And I end up with a bunch of branch names with "behdad-" prefixes that I can explore or blow away if I'm no longer interested, (could have used a "behdad/" prefix as well). The first problem we ran into when doing that months ago was that I don't want any tracking branches to come across this way. Or else I end up with behdad-origin, he then gets cworth-behdad-origin, ad nauseum. So we filtered "origin" out, but it will be nice to revisit this if there's a sane distinction in git now to separate tracking branches from heads. > And I think "git fetch" is the tool for what you want if > enhanced properly; see Linus's message that explaind that we > already have that support in "manually configurable" form but > initializing and maintaining the configuration is currently all > manual and can be improved. Yes, git-fetch is lovely, and it's the need for manual configuration that's a problem, (and the mixing up of heads and remote tracking branches that has been in git historically). So, yes, I'll definitely look into improving this. I think the details will involve: 1. Making clone do the --use-separate-remotes behavior by default 2. Taking advantage of that consistently for all branches instead of a special master:origin mapping in clone 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was there a desire for some other branch-specific section in the config file?) 4. Making git-fetch handle the disappearance of a remote branch gracefully 5. Adding something like git-fetch --all to allow it to pick up all new branches 6. Adding a "git update" that does a fetch for all appropriately marked remotes. On this last point, maybe we do something like: update=no|yes|all in .git/remotes. Then git-clone would set this up with update=all for origin so git-update would do a "fetch --all" on the origin repository. Then step 3 above would have to provide for setting this update option as appropriate. Anyway, something along those lines perhaps. Any feedback? -Carl
Attachment:
pgpcAX61dgQTE.pgp
Description: PGP signature