From: Junio C Hamano Date: Mon, 26 Sep 2005 20:25:28 GMT Subject: Re: GIT 0.99.7d, and end of week status. Message-ID: <7vll1jh8zr.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20050926191037.GD26340@pasky.or.cz> Petr Baudis writes: > ... Either way, git-pull won't be equivalent to git-fetch && > git-merge (or git-resolve or whatever is the core porcelain > command) anymore. "pull = fetch + merge" is a reasonable approximation to use when you explain what they are to somebody, but taking it literally would harm usefulness. It is what you have already lived with for a while. "git pull .../linux/2.6.git v2.6.11-tree v2.6.12" would fetch both heads but merges v2.6.12 head only (because v2.6.11-tree is not something you can merge with). The typical use cases are: - The remote does not have more than one head (majority of the kernel.org repositories are single head repositories). You could say "Pull: master:somebody" in .git/remotes/somebody and say "git pull somebody" and pull is fetch + merge. The proposed fix does not affect this case. - The remote has more than one heads, and they are usually both interesting. Some kernel.org repositories have release and test heads and people who are interested in what is happening in that subsystem are likely to want to inspect both, so fetching both makes a lot of sense (especially given multi-head fetch over git-native protocol is more efficieint than fetching them separately), but obviously merging both into an Octopus does not make any sense most of the time. You could say "Pull: release:a/release test:a/test" in .git/remotes/subsys and "git fetch subsys" would fetch both and store them locally. "git pull subsys" would fetch both but merges only subs/release, which is far more useful than attempting to make an Octopus with both heads. You could still say "git pull subsys test" to only fetch and merge test, if you needed to do something different from what the "merge only the first one by default" rule gives. - The remote has 47 different heads, and they are more or less independent developments in the same area ("topic branches"). Jeff's libata-dev repository may be a good example. "Pull: ALL:libata-dev/ALL ncq:libata-dev/ncq chs-support:libata-dev/chs-support ..." would be what one would place in .git/remotes/libata-dev. This list can be a subset of the heads that exist at remote but only the heads one is interested in. "git fetch libata-dev" would get all the heads in that repository one is interested in, "git pull libata-dev" would merge in ALL (which is premerged at the remote side) thanks to the "merge only first one by default" rule. If you want to make Octopus with selected heads (not the one Jeff made in ALL), you still can say "git pull libata-dev ncq chs-support" to do so.