On Thu, Feb 08, 2007 at 09:27:32AM -0600, Bill Lear wrote:
If it is on the LHS, it's talking about the branch in the _remote_ repo.
It means to fetch the remote's branch "refs/heads/topic" and store the
current head in _your_ "refs/heads/topic" as a tracking branch, but only
if it's a fast-forward. Yes, I know it says "Pull:", but it's really
about fetching.
You can then merge the result of that fetch into your current branch. So
what you want is something like:
Pull: refs/heads/topics:refs/heads/remote-topic
which will use 'remote-topic' as a tracking branch, always updating it
at fetch time to reflect the remote's version of topic. You can then
merge remote-topic into your local topic branch by fetching+merging, or
by doing 'git-pull remote refs/heads/topic:refs/heads/remote-topic'.
I believe he means 'store commits in'. That is, the RHS of the refspec
should be used solely for tracking fetches from the remote. If you make
a commit on top of it (either directly, or by doing a merge), then the
fetch must either throw away your commits, or fail to fast-forward to
the remote's new position for that branch.
Yes. It will basically give you a RHS of "refs/remotes/$REMOTE/$BRANCH"
to track a branch $BRANCH coming from $REMOTE (generally "origin"); it's
a more organized way of doing what I mentioned above (RHS of
refs/heads/remote-topic).
Most people think so (though I think Junio actually still uses the
traditional layout, because he finds it more convenient). Note that in
1.5, --use-separate-remote is the default (the option is still
accepted, but has no effect; note also that the option is singular).
No, you will not shoot yourself because the fetch part of the pull will
store the remote's position of 'refs/heads/topic' at
'refs/remotes/origin/topic' instead of trying to overwrite the branch
you've been working on.
As an additional bonus, you can put this in your .git/config:
[branch "topic"]
remote = origin
merge = refs/heads/topic
which means "When I'm on my refs/heads/topic branch and I issue a
git-pull without any arguments, do a git-fetch on origin. Then, merge
what the remote end calls refs/heads/topic into my current branch."
Without this, git-pull in v1.4.* will attempt to merge the remote's
'master' branch. In v1.5, I believe it will refuse to make a merge.
That is correct. If you add the config I mentioned above, you can get
the "automatically merge from remote topic into my topic" behavior that
you get for master.
Syncing repositories doesn't involve pulling. It just involves fetching.
So in either case, you can simply do a 'git-fetch origin'. In v1.5,
the repositories won't be exactly identical; your remote branches will
be stored in refs/remotes/origin instead of refs/heads.
However, your original setup is still broken for syncing. You are doing
local work on refs/heads/topic, but you also are claiming you want to
store the sync of the remote in refs/heads/topic. You obviously can't do
both.
Maybe I don't understand what you mean by sync here, but I don't see the
mental leap. Whenever you fetch, from whatever branch, using the
'origin' remote, it will update all tracking branches in your local
repository. You can then selectively do merges to any local branches
you're working on. You _can't_ do an operation that is "for every local
branch I have, merge the matching remote branch into my local branch".
And I don't think you'd want to: a merge may or may not be a trivial
thing, since it might have conflicts.
The workflows I suspect you want are:
1. I'm working on my topic, and somebody else is working on topic. Pull
their work from the remote 'origin':
git checkout topic
hack hack hack
git commit
git pull origin
Using separate remotes, you'll get a copy of the remote topic branch
in your refs/remotes/origin/topic. If you have the config magic I
mentioned above, it will automagically pull from his topic branch. If
not, it will either pull from his master (v1.4) or complain (v1.5).
2. I'm working on my topic, and now I want to pull from the remote
master to do some testing.
git checkout topic
hack hack hack
git commit
git fetch origin
git merge origin/master
This will only work in v1.5. Using separate remotes, the
'origin/master' branch refers to the 'refs/remotes/origin/master'
tracking branch. You could do it in v1.4 like this (without using a
tracking branch at all):
git pull origin master
3. I'm interested in what's happening on the topic branch, but I don't
care about making local commits. I just want to build it.
git checkout origin/topic
build build build
It assumes you are tracking using separate remotes (hence the
origin/topic branch). This will _only_ work in v1.5, since you're
not allowed to checkout any non-branch refs in v1.4 (including tags
or remote tracking branches). The moral equivalent in v1.4 using
separate remotes is:
git checkout -b topic origin/topic
build build build
which leaves you with your own local 'topic' branch, which you can
then merge into if you want.
Hope that makes sense.
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
