On Mon, Jan 01, 2007 at 03:56:05PM -0800, Luben Tuikov wrote:
quoted text
> > Currently, today, if you type:
> > 
> > 	git fetch <non-URL>
> > 
> > ... it will look up "<non-URL>" in a single global namespace, which
> > (using only the new config scheme) is looked up in remote.<non-URL>
> > and remote.<non-URL>.{url,fetch} is used to control the operation of
> > git-fetch.
> 
> I'm talking about more in terms of git-merge, but since git-pull
> is a git-fetch and git-merge, I've been using git-pull for completeness.

Well, yes; since git-pull is implemented in terms of git-fetch
followed by a git-merge, that's why I talked about git-fetch.  It is
git-fetch which uses remote.<non-URL>.{url,fetch}, not git-merge or
git-pull (since it just passes those arguments over to git-fetch).

quoted text
> More specifically,
> branch.<branch-match>.<symbolic-ref match>.{fetch,merge}.

What do you mean by <branch-match> and <symbolic-ref match>?

Are you assuming some kind of glob match?  If so, what are the
specific rules of the match that you are proposing?

quoted text
> branch.<branch-match>..{fetch,merge} is allowed and defalts
> to already implemented "git-pull".

What do you mean by ".." here?   

quoted text
> Think of "git-pull", not just of "git-fetch".  As well as think
> of a setup where there are more than one branch implementing
> software dependency, resolving to a software product.

git-pull is implemented in terms of git-fetch.  So if we make the
change to git-fetch, the changes naturally follow to git-pull.  Or are
you proposing to change that?

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html