--- Theodore Tso <tytso@xxxxxxx> wrote:
> 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".
> 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.
> 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
-
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