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

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Jan 1, 2007, 23:56 UTC
Message-ID: <926020.70066.qm@web31802.mail.mud.yahoo.com>
In-Reply-To: <20070101131726.GA21933@thunk.org>

--- Theodore Tso <tytso@mit.edu> wrote:

Show 6 quoted lines

> Luben,
> 
> Let me see if I can understand what you are asking for without using
> the term "branch spec", which I don't think has been adequately
> defined yet in this thread.  (Where "the SCM industry has adopted"
> isn't a definition.  :-)

You can also think of it as "the merge direction given a symbolic name".

Show 8 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. IOW, I've tried to concentrate on a per-repo operations (merge) as opposed to on a multi-repo, which is currently handled by git as is expected.

> What you want to do is to change this to where:
> 
> 	git fetch <non-URL>

git-pull, for completeness.  See my paragraph above.

> ...will now lookup "<non-URL>" in a namespace which is qualified by
> the branch that you are in.  So you want to look up the information in
> branches.<current-branch>.<non-URL>.{url,fetch} instead.

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

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

branch..<symbolic-ref match>.{fetch,merge} is forbidden since it is essentially remotes/ and is handled by the current "remotes/" infrastructure by git.

branch.<branch-match>.<symbolic-ref match>.{fetch,merge} will perform the fetch, which would be a no-op, since the branch we're "fetching" is local, and the merge merges into the current branch if it matches.

Show 6 quoted lines

> You haven't stated it explicitly, but I assume that if
> branches.<current-branch>.<non-URL> doesn't exist, you're proposing
> that the code fall back to looking in the old configuration parameter,
> remote.<non-URL>, so that certain names that should be global can
> continue to be global, and that people who want a single global
> namespace can continue to have it?

Yes, I absolutely do not want to break existing behavior. But if it is extended, it should be done properly, and a general case should be solved as to solve this once and forever.

> Is that your proposal, stripped of the arguments of why you want it,
> and of the somewhat confusing "parent" example (which is a bad one
> given that your "git pull parent" example was the semantic equivalent
> of "git pull")?

More or less. Basically, I want local "git-pull" (fetch[no-op],merge) to be addressable, i.e. _named_, so that I can establish a more complex software dependency, which I currently do, my means of the order and the type of "git-pull . <branch>" I do.

> If it is, I'm a bit nervous since it's making the git-fetch command
> modal, and modal UI's are confusing to users.

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.

> On the other hand, it's
> a fundamental modality we have already (based on the question "which
> branch am I"), and there are hacks that will allow you to put the
> current branch into your command-line.

Ah, yes. Well, the many-branches-one-directory is confusing and is modal. *But*, it doesn't have to be like that. Git allows the freedom to define branch-per-directory-yet-single-repo which I've absolutely always used with GIT, and other SCMs. This way it is absolutely unambiguous "what branch I'm at".

It is in this sense that I do "cd <branch>; git-pull . <branch>" in a sequence, and I'd rather do "cd <branch>; git-pull <symbolic-ref>" to define which branch is the merge coming from given the current branch _and_ the symbolic ref.

> And as long as you are
> proposing a lookup in branches.current.branch.<non-URL> first before
> checking remotes.<non-URL> it seems mostly harmless to me.  I doubt
> I'd ever use it, but maybe it would be helpful to some.

Yes, current behavior should absolutely not be broken. First (<current-branch>,<symbolic-ref>) is matched against "branch.<name>.<symbolic-ref>.{fetch,merge}" modulo the cases I've outlined before, and then if everything else fails, we default to remote/.

     Luben