From: Luben Tuikov <ltuikov@yahoo•com>
To: "J. Bruce Fields" <bfields@fieldses•org>
Cc: Junio C Hamano <junkio@cox•net>,
git@vger•kernel.org, Shawn Pearce <spearce@spearce•org>,
Johannes Schindelin <Johannes.Schindelin@gmx•de>
Subject: Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
Date: Sun, 31 Dec 2006 23:53:53 -0800 (PST) [thread overview]
Message-ID: <452383.57759.qm@web31813.mail.mud.yahoo.com> (raw)
In-Reply-To: <20070101054536.GG15537@fieldses.org>
--- "J. Bruce Fields" <bfields@fieldses•org> wrote:
> On Sun, Dec 31, 2006 at 09:13:49PM -0800, Luben Tuikov wrote:
> > Yes, but I don't want to just type "git-pull", I want to explicitly
> > type "git-pull parent" and depending in which branch I'm at, "parent"
> > would have identical meaning but would merge a different branch... because
> > I'm in a different branch...
>
> Wouldn't it do what you want if by default "git branch new" and "git
> checkout -b new" set branch.* options that pointed at the "parent"
> branch?
Technically yes. Presentationally no.
> The only reason I can see to require the extra bit of syntax ("git-pull
> parent" instead of "git-pull") is if for the same branch you expect to
> sometimes pull from one source and sometimes from another, and the pulls
> from those various sources are common enough that it's worth defining
> some shortcuts for more than one of them.
Exactly.
> I can imagine sometimes doing that. (E.g. if you pull into your master
> branch from upstream and from local topic branches.) But in that case
> having to give the remote and branch name explicitly doesn't seem so
> bad.
Basically I want to _name_ the dependency, instead of having it be
implicit. One can extend that dependency, in more complicated
topic branch relationship, where for example, C extends B, B extends
A, A extends master, but B' also extends A, consider B' a "version"
of the extension which B implements. This is of course a trivial
example and more complicated ones exist.
Naming the dependency would give git greater coverage when it needs
to implement complicated source development environments and code
relationship. IOW, it is the way to go. Having a single implicit
dependency is just a crutch, half-way there.
Or, one can look at it in a different way, extending the
remote/ functionality as is, but instead of being remote-pulls-
into-local, extending for local pulls into local.
I.e. the remote relationship is named, I'd like to extend
this locally as well.
Consider the examples of "branch.<name>.<symbolic_ref>.{fetch, merge}"
I gave in a previous email in this thread.
Luben
next prev parent reply other threads:[~2007-01-01 7:53 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 [this message]
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
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=452383.57759.qm@web31813.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 \
/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