Re: defaults for where to merge from
From: Andy Parkins <hidden>
Date: 2016-06-15 22:42:57
On Wednesday 2007 February 28 14:53, Paolo Bonzini wrote:
As can be seen from my other messages, I'm experimenting a little with git and trying to understand how its workflow compares with arch. Right now, my procedure for branching off a remote archive is: git checkout -b branchname remote/upstreambranch git config --add branch.branchname.remote remote git config --add branch.branchname.merge refs/heads/upstreambranch Is there a reason why "git branch" and "git checkout -b" should not automatically do the two "git-config --add"s when the source branch is remote?
I can see why that would be handy, but I often make short lived branches off a remote; and I wouldn't want my config cluttered up with branch defintions.
In case the source branch is not remote, would "origin" be a good choice for the "branch.branchname.remote" variable?
No. That would still reference a remote. As in:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = origin
merge = refs/heads/master
The remote = origin tells git to use the [remote "origin"] section.
I think what you want is something that I would like too. If you specify "."
to a git-pull it means to use the local repository not a remote. It would be
great if one could have:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = .
merge = refs/remotes/origin/master
That way a "git pull" on master wouldn't need to make a remote connection in
order to do a merge (which is the way I like it). However, I remember there
was a reason this wouldn't work, but I don't remember what it was :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com