Carl Worth <cworth@xxxxxxxxxx> writes: > 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). I would suggest refs/remotes/behdad. > 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 This already should be the case if you use separate-remote. I haven't run "clone --separate-remote" myself for a long time, but the design was certainly to make it behave that way. Specifically, map everything in refs/heads/ at remote to refs/remotes/$origin/ with corresponding names, one-to-one. I do not see much reason to change the mapping of master:origin which is done for the traditional layout. The traditional layout is not suitable for your workflow anyway, and that is why you prefer separate-remote layout for your project, and I fully agree it would suit you better. > 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 These three are easily done for separate-remote layout but at that point you would not want --all but more powerful --mirror (or --update if you want to use that word), which goes the whole nine yards of noticing disappearance of remote branch, making matching deletion of local tracking branch, updating .git/remotes, etc. I've muttered something similar in a nearby thread; see below. > 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. I would prefer this to be kept in contrib/; it feels like it is filling rather very narrow need. > Anyway, something along those lines perhaps. Any feedback? I muttered something less elaborate in the nearby thread. Message-ID: <7vr6w78b4x.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> Message-ID: <7v64dev88t.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> The part that deals with manual configuration (the last point in the first message, and the second in message its entirety) is something your workflow would not need nor want to worry about, but I think it is necessary for different ref namespace layouts and different workflows. I think the automatable part (the first two points in the "sensible thing to do" list in the first message) is very relevant to what you talked about in your message. - 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