Re: defaults for where to merge from

[Andy Parkins <andyparkins@gmail.com>]

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