Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior

From: Theodore Tso <tytso@mit.edu>
Date: Jan 2, 2007, 01:08 UTC
Message-ID: <20070102010816.GB4253@thunk.org>
In-Reply-To: <926020.70066.qm@web31802.mail.mud.yahoo.com>

On Mon, Jan 01, 2007 at 03:56:05PM -0800, Luben Tuikov wrote:

Show 11 quoted lines

> > 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