--- Theodore Tso <tytso@xxxxxxx> wrote:
> 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?
Yes. I've outlined them at least twice in this thread
already as well as in that same email of mine which you're replying
to, which I'm replying to.
> > branch.<branch-match>..{fetch,merge} is allowed and defalts
> > to already implemented "git-pull".
>
> What do you mean by ".." here?
I mean "git-pull", as opposed to "git-pull <symbolic-ref>".
I.e. "branch.<branch-match>..{fetch,merge}" matches no symbolic
ref given, exactly what it defines.
> > 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?
No, not at all.
Please see my last email to Junio in this thread. Depending on
how this new functionlity is implemented for git 1.5, the concept
of "branch spec" can be had by using a "dummy" [remote] spec,
used only as a command line match, and specifying the merge
dependency in the [branch] spec, refering to "remote" and
identifying what to merge. See that email please.
Luben
-
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