Re: Question on multi-level git repository heiarchy.

[linux@horizon.com]

The thing to learn is that the operation you are trying to perform
is called "fetch", not "pull".  Pull = fetch + merge.

In fact, the "fetch" part of "git pull" is optional, so it's
best to think of "git pull" as the fundamental *merge* operation.
("git merge" is a helper that you probably don't want to use directly.)

There's a valid argument that this is not good terminology (especially
because "push" is the opposite of "fetch"!), but without getting
into that discussion, there are two ways to do a merge:

- The small-steps way.
  git fetch remote
  git pull . remoteorigin

- The bold, all-at-once way
  git pull remote remoteorigin

The former acutally gives a local name to the remote branch,
then merges it in in a second step.

The latter is what folks like Linus do who aren't carefully following
remote development, but just want to merge it in.  It's better for
one-off access to remote development, because it doesn't clutter your
reporistory with a remote branch name that you're not going to use again.

Generally, I always do the former, and I recommend you do too, until
you're comfortable with making such big leaps.

Just remember:
1) "git fetch" copies from the remote repository to the local one.
   This doesn't change anything locally except for branch heads that
   it's supposed to.  And even there, it's careful.
   In particular, "git fetch" will refuse to modify the current HEAD.

2) "git pull" actually does a merge.  This *does* change the current
   HEAD.  It creates a new commit on the HEAD branch unless:
   - HEAD is already up to date, or
   - HEAD can be fast-forwarded, or
   - The merge fails.