On 2006-11-02 22:45:49 -0500, Sean wrote: > One thing that would make separate-remotes nicer to work with is to > have an automatic mapping between any local branch and one of the > same name in remotes. > > So for instance, if you have a local branch named pu checked out and > you pull from origin, remotes/origin/pu would be merged after the > fetch unless a manual mapping was defined in the remotes or config > file. I would rather see the default pull source of a branch being determined by which branch it was branched off of. But this should mean the same thing in this case. We'd just have to have the heuristic that default pulls from a remotes/*/* branch causes a fetch, while a default pull from a local branch does not. > Maybe even going as far as automatically creating a local branch for > each remote branch on clone is worth considering. Yes, maybe. It should make for a good default for beginners, at least. > On a peripherally related topic, someone on the xorg list was > complaining that after the initial clone, there is no easy way to > track branches that get added/deleted from the remote repo. It would > be nice if pull had an option to automatically add and remove remote > branches from the remotes/<remote>/xxx namespace. That would definitely be useful. But I want it in fetch, not pull. :-) Well, I suppose it could be in both. Hmm, I think my dislike of remote pulls can be summed up as: I find it convoluted to have a command that will fetch multiple remote branches, then merge just one of them into my current branch. (I have no problem with pull when the branches to pull are specified explicitly, since in that case they are all merged.) With explicitly specified default pull sources it would get better, since then I would know that the correct branch would be merged, but I still don't quite like it. -- Karl Hasselström, kha@xxxxxxxxxxx www.treskal.com/kalle - 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