Re: GIT 0.99.7d, and end of week status.

Petr Baudis <pasky@suse.cz> writes:

"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.