From: Luben Tuikov <ltuikov@yahoo•com>
To: Theodore Tso <tytso@mit•edu>
Cc: Junio C Hamano <junkio@cox•net>,
git@vger•kernel.org, Shawn Pearce <spearce@spearce•org>,
Johannes Schindelin <Johannes.Schindelin@gmx•de>,
"J. Bruce Fields" <bfields@fieldses•org>
Subject: Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
Date: Mon, 1 Jan 2007 15:56:05 -0800 (PST) [thread overview]
Message-ID: <926020.70066.qm@web31802.mail.mud.yahoo.com> (raw)
In-Reply-To: <20070101131726.GA21933@thunk.org>
--- Theodore Tso <tytso@mit•edu> 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
next prev parent reply other threads:[~2007-01-01 23:56 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-31 23:47 [PATCH] Docs: update cvs-migration.txt to reflect clone's new default behavior bfields
2006-12-31 23:47 ` [PATCH] Documentation: update git-clone.txt for " bfields
2006-12-31 23:47 ` [PATCH] Documentation: update git-pull.txt " bfields
2006-12-31 23:47 ` [PATCH] Documentation: update glossary entry for "origin" bfields
2006-12-31 23:47 ` [PATCH] Documentation: remove master:origin example from pull-fetch-param.txt bfields
2006-12-31 23:47 ` [PATCH] Documentation: update tutorial's discussion of origin bfields
2007-01-01 0:35 ` [PATCH] Documentation: update git-pull.txt for clone's new default behavior Junio C Hamano
2007-01-01 1:12 ` J. Bruce Fields
2007-01-01 1:44 ` Junio C Hamano
2007-01-01 3:29 ` Luben Tuikov
2007-01-01 3:48 ` J. Bruce Fields
2007-01-01 5:13 ` Luben Tuikov
2007-01-01 5:45 ` J. Bruce Fields
2007-01-01 7:53 ` Luben Tuikov
2007-01-01 7:38 ` Junio C Hamano
2007-01-01 8:19 ` Luben Tuikov
2007-01-01 13:17 ` Theodore Tso
2007-01-01 23:56 ` Luben Tuikov [this message]
2007-01-02 1:08 ` Theodore Tso
2007-01-02 2:17 ` Luben Tuikov
2007-01-02 3:45 ` Junio C Hamano
2007-01-02 18:39 ` Luben Tuikov
2007-01-01 21:39 ` J. Bruce Fields
2007-01-01 21:40 ` J. Bruce Fields
2007-01-02 0:01 ` Luben Tuikov
2007-01-02 0:10 ` J. Bruce Fields
2007-01-02 0:57 ` Theodore Tso
2007-01-02 1:28 ` Luben Tuikov
2007-01-02 6:32 ` Junio C Hamano
2007-01-02 2:09 ` Luben Tuikov
2007-01-02 0:21 ` Junio C Hamano
2007-01-02 0:38 ` Jakub Narebski
2007-01-02 2:05 ` Luben Tuikov
2007-01-02 3:36 ` Junio C Hamano
2007-01-02 11:31 ` Jakub Narebski
2007-01-02 18:48 ` Luben Tuikov
2007-01-02 19:22 ` Jakub Narebski
2007-01-02 19:30 ` Junio C Hamano
2007-01-05 23:15 ` Luben Tuikov
2007-01-05 23:20 ` Junio C Hamano
2007-01-05 23:32 ` Junio C Hamano
2007-01-06 0:32 ` Luben Tuikov
2007-01-06 0:22 ` Luben Tuikov
2007-01-06 1:17 ` Junio C Hamano
2007-01-01 23:59 ` Luben Tuikov
2007-01-02 0:06 ` J. Bruce Fields
2007-01-02 0:12 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=926020.70066.qm@web31802.mail.mud.yahoo.com \
--to=ltuikov@yahoo$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=bfields@fieldses$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
--cc=spearce@spearce$(echo .)org \
--cc=tytso@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox