Sean <seanlkml@xxxxxxxxxxxx> wrote: > On Thu, 02 Nov 2006 18:40:30 -0800 > Junio C Hamano <junkio@xxxxxxx> wrote: > > > which is efficient (guaranteed to do only one fetch from remote) > > and convenient. Also I have Push: mapping set up on my > > main machine to do master:origin, next:next, maint:maint, and > > +pu:pu so that I can replace the first "git pull" on the > > secondary machine with "git push secondary" on my main machine. > > 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. > > Maybe even going as far as automatically creating a local branch > for each remote branch on clone is worth considering. Nack. I work with a workflow where our central repository has 2 important branches (vmtip and vmvt), and a bunch of transient developer topic branches (e.g. sp/foo). We only have a master branch in this repository so that git-clone will clone it without choking during the clone. Users tend to do immediately after a clone: git branch -D master git branch -D origin git branch -D ... other topic branches not interested in ... edit .git/remotes/origin ... delete topic branches ... Why? Because vmtip and vmdvt have meaning to these users, much as pu has meaning. Really vmtip is roughly equal to master in Git and vmdvt is roughly equal to maint but not having the mental mapping of "vmtip == master" just makes things easier. Creating a local branch for every remote branch would just make things worse in the above workflow; not to mention it makes it confusing for other users who might be fetching into a repository and expecting their local "next" to to update automatically after a fetch... > 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. Or at least deleting/skipping over a branch you listed to fetch from the remote that no longer happnes to be on the remote. This is causing some pain due to the topic branches noted above. -- Shawn. - 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