On 04/14/2007 08:24 AM, Junio C Hamano wrote:
I think adding these lines to .git/config would do the trick,
after you have done the "checkout -b v2.6.20 v2.6.20" step:
[branch "v2.6.20"]
remote = stable
merge = refs/heads/master
[remote "stable"]
url = git://git.kernel.org/.../stable/linux-2.6.20.y.git
fetch = refs/heads/master
provided if stable team forks v2.6.20.y history off of Linus's
v2.6.20.
With the above configuration, anytime you say "git pull" while
on your v2.6.20 branch will fetch from "stable" and merge their
'master' branch in your current branch (i.e. v2.6.20 branch).
Yes, this does seem to work, thanks. Was thrown of a bit by having named the
branch "v2.6.20". GIT and I disagree what it is that I want to happen when I
say "git checkout v2.6.20" if v2.6.20 is also a tag on master.
The pull behaviour does not follow further branches:
rene@7ixe4:~/src/linux/local$ git branch
* 2.6.20
master
rene@7ixe4:~/src/linux/local$ git checkout -b 7ixe4
Switched to a new branch "7ixe4"
rene@7ixe4:~/src/linux/local$ git pull
Warning: No merge candidate found because value of config option
"branch.7ixe4.merge" does not match any remote branch fetched.
No changes.
This might in practice not be all bad in fact, and I suppose I understand
how to "fix" it along the same lines as above.
But as happens very frequently with GIT, I get the feeling that I just don't
understand how it's all intended to be used. It seems that what I wanted
above is not standard? What would be expected use of the stable GIT repo?
Just cloning that outright into another repo?
A "GIT WHYTO" from someone with the oversight would be very useful...
Rene.
-
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