On Nov 12, 2009, at 3:17 PM, Jan Nieuwenhuizen wrote:
Okay, so now I have
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "origin"]
url = git@xxxxxxxxxx:janneke/gub.git
fetch = +refs/heads/*:refs/remotes/origin/*
# advise from git pull, using <nickname> = eddy
# branch.master.remote = <nickname>
# branch.master.merge = <remote-ref>
# remote.<nickname>.url = <url>
# remote.<nickname>.fetch = <refspec>
#[branch "master"]
# remote = eddy
# merge = refs/heads/master
[remote "eddy"]
url = http://github.com/epronk/gub.git
#use remote.eddy.fetch to +refs/heads/*:refs/remotes/eddy/*.
fetch = +refs/heads/*:refs/remotes/eddy/*
It looked promising, but still get
15:00:20 janneke@peder:~/vc/gub
$ git pull -r --verbose
From git@xxxxxxxxxx:janneke/gub
= [up to date] lilypond-release-branch -> origin/lilypond-
release-branch
= [up to date] master -> origin/master
Current branch master is up to date.
15:00:26 janneke@peder:~/vc/gub
$ git pull -r --verbose eddy
From http://github.com/epronk/gub
= [up to date] lilypond-release-branch -> eddy/lilypond-
release-branch
= [up to date] master -> eddy/master
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
specify which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
[1]15:00:33 janneke@peder:~/vc/gub
$
Do you want to rebase on top of origin or eddy? It doesn't make sense
to rebase on top of both.
With git you usually develop new features in branches and then merge
the result into the master branch once it's ready. So you would use a
branch 'feature-X' and there you work on your feature. Since it's your
private/local branch, you can rebase it however you want. In the
meantime eddy has also worked on some new cool features, and now that
he's ready he told you to pull from his branch. So you 'git checkout
master; git pull eddy master' to merge his new features. Then you can
push the result into your github repo, checkout feature-X and rebase
that on top of the new origin/master. Once your feature is done, you
can checkout master, merge feature-X and push that to github.
Another reason not to rebase on top of eddy's master branch is this:
if is master is behind your master (eg. your master has commits that
his master doesn't), and you rebase on top of his master, you loose
the commits.
After this I started to re-read git-config's man page
again. There is something strange that I do not understand
branch.<name>.merge
Defines, together with branch.<name>.remote, the upstream
branch for the given branch. It tells git-fetch/git-pull
which branch to merge and can also affect git-push (see
push.default).
this seems to imply that the merge variable here
[branch "master"]
remote = FOOBAR
merge = refs/heads/master
is somehow tied to the remote nick FOOBAR. That would
mean it is actually taken as
branch.<name>.<nickname>.merge
and also that it's impossible to specify more than one
<nickname>. That would be make nicknames unusable and
thus silly, so I cannot be right?
It seems like 'git pull <remote>' doesn't work. Either use 'git pull',
in which case git takes the needed info from
branch.<name>.remote/.merge, or use 'git pull <remote> <branch>' in
which case git will use the info from the commandline. It doesn't make
much sense to say 'pull from X but rebase on top of the same remote
branch name as if you'd pull from Y'.
tom
--
To unsubscribe from this list: 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