On Mon, Jan 01, 2007 at 03:56:05PM -0800, Luben Tuikov wrote:
> > 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).
> 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?
> branch.<branch-match>..{fetch,merge} is allowed and defalts
> to already implemented "git-pull".
What do you mean by ".." here?
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html