Pavel Roskin <proski@xxxxxxx> writes: > This is not a ready-to-use proposal, but I think my message can prompt > useful changes in GIT or in the "porcelain". >... > I think it would be convenient to have git remember the remote branch > for the given local branch. git should know that if HEAD points to > "local-B", "git-fetch" should fetch from "remote-B", not from "origin". I am in favor of the general direction this is going. Something like this was mentioned on the list in the past twice (I think Johannes was involved in the discussion but I do not remember the details offhand). My understanding is that Cogito uses $GIT_DIR/branches/$name file as a configuration file per branch - currently it only records which remote repository's what remote branch the local branch $name interfaces with. The $GIT_DIR/remotes/$name file is to describe each remote repository, and it _wants_ to be able to describe all the branches we are interested in, primarily because uploading and downloading multiple, related heads at once is more efficient. How remote branches are kept track of with the local tracking branch, and how remote branches are updated from the local branch heads, are described by Push/Pull lines there. As you pointed out, we do not have a convenient way to tell git where you typically merge things from per local branch. There are different patterns I've seen: - Promiscous. For example, "master" branch of Linus repository pulls from many subsystem maintainers. Linus could have one "remotes" file per subsystem maintainer he often pulls from (and "for-linus" branch name in each remote repository tends to stay the same), and unlike the rest of us he does not seem to pull into many local branches. The current "remotes" setup is really optimized for this mode of usage (you can use "remotes" without having local tracking branches). - Merging topic branches into "master" (or "release") branch and "next" (or "testing") branch -- inside local repository. - CVS-like remote tracking. A single "primary" remote branch is tracked using local "origin", merged into local "master" and pushed back to the remote. Both Cogito-like branches/ setup and having a single $GIT_DIR/remotes/origin file with single Push/Pull line would work equally well. - Multiple subsystem maintainer trees tracked in the same local repository. Most generally, two local branches per each remote head can be used (one tracking branch to fetch into, another to build your changes based on it). Alternatively, you can use one local branch per each remote head without using any tracking branch. Your proposal to give default branch to pull from per the local branch would help only the last case. The first one you do not switch between local branches at all and pull from many different places; the second is to merge from different topic branches from time to time and does not benefit from fixed configuration; the third does not even need configuration. Maybe you would want something like this. In $GIT_DIR/config: [pull] origin = linus for master origin = irq-pio of libata for ata-irq-pio origin = pata-drivers of libata for ata-pata In $GIT_DIR/remotes/linus: URL: git://git.kernel.org/.../torvalds/linux-2.6.git Pull: refs/heads/master:refs/heads/linus In $GIT_DIR/remotes/libata URL: git://git.kernel.org/.../jgarzik/libata-dev.git Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio Pull: refs/heads/pata-drivers:refs/remotes/libata/pata-drivers This is to maintain three local branches: master, ata-irq-pio and ata-pata. You are obviously interested in the mainline Linus kernel, so while you are on your "master" branch, we will look for "pull.origin .* for master" and find out you would want remotes/linus file to be used. His "master" is copied to your local "linus" branch, and merged into your "master" branch. $ git pull becomes equivalent to: $ git pull linus You are also interested in the libata work by Jeff, and while you are on your ata-pata branch $ git pull becomes roughly equivalent to: $ git pull libata pata-drivers While we are on the topic, it _might_ be worthwhile to think about revamping the syntax of $GIT_DIR/remotes file, maybe even breaking backward compatibility. The Pull: lines can be independently specified which gives flexibility, but I suspect local tracking branches from the same remote tend to live in the same place; IOW, you would probably not do something like: URL: git://git.kernel.org/.../jgarzik/libata-dev.git Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio Pull: refs/heads/pata-drivers:refs/heads/pata-drivers in practice. - : 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