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 18:17:13 -0800 (PST) [thread overview]
Message-ID: <199618.57093.qm@web31811.mail.mud.yahoo.com> (raw)
In-Reply-To: <20070102010816.GB4253@thunk.org>
--- Theodore Tso <tytso@mit•edu> 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
next prev parent reply other threads:[~2007-01-02 2:17 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
2007-01-02 1:08 ` Theodore Tso
2007-01-02 2:17 ` Luben Tuikov [this message]
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=199618.57093.qm@web31811.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