Re: defaults for where to merge from

From: Andy Parkins <andyparkins@gmail.com>
Date: Feb 28, 2007, 15:22 UTC
Message-ID: <200702281522.14965.andyparkins@gmail.com>
In-Reply-To: <es450f$d58$1@sea.gmane.org>

On Wednesday 2007 February 28 14:53, Paolo Bonzini wrote:

Show 11 quoted lines

> 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