From: Luben Tuikov <ltuikov@yahoo•com>
To: Junio C Hamano <junkio@cox•net>
Cc: 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 00:19:45 -0800 (PST) [thread overview]
Message-ID: <997672.38239.qm@web31814.mail.mud.yahoo.com> (raw)
In-Reply-To: <7vfyav8ae1.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox•net> wrote:
> Luben Tuikov <ltuikov@yahoo•com> writes:
>
> > --- "J. Bruce Fields" <bfields@fieldses•org> wrote:
> > ...
> >> Could you explain a situation where this would be useful?
> >
> > I don't know how to respond to this question.
> >
> >> A
> >> "parent<-->child" relationship, where there's one upstream branch that
> >> is always merged in, is easily handled;
> >
> > e is the base of natural logarithms.
>
> You lost me here; I am guessing this is some sarcasm not worth
> paying attention to, so I'd ignore this part for now.
Absolutely correct. I just needed to respond to an obvious fact with
another obvious fact.
> >> just replace your "git pull parent" by a "git pull", right?
> >
> > 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...
> >
> >> Am I misunderstanding the proposal?
> >
> > I did give an example of usage in my email to which you replied.
>
> But what confuses me (and I think JBF shares the same confusion
> with me) is that you had only one example "parent".
More complicated and exotic examples exist. See my response
to JBF, which I just posted a moment ago.
> While I understand that it would make sense to define "parent"
No, no, no. Forget about the semantic attibute of "parent".
I could've called it "xyz" for that matter.
What I'm talking about is the concept of "branch spec". It
is a well known concept in SCMs.
We currently implement it, in git specific way, for remotes/
only, but not for local ("topic") branches.
Another way to look at it is that a Topic, can have many
other self-contained sub-Topics, each one building on the one
"before" it, extending it, yet introducing new functionality,
and only in the "leaf" branch, do you get a fully capable software.
Each sub-topic branch is also a working software but only implements
part of the functionality of your product and/or toned down version
of it, say if someone doesn't want support for feature ABC, which
uses 100MiB of memory...
> for each branch in a downstream developer's workflow, (1) I do
> not see the difference between your wording, "parent", and what
> we traditionally have called "origin",
I've always contended that it is the same and had mentioned
that it is only implemented for remotes/.
> and (2) I do not think of
> relationship other than "parent" ("origin") that is applicable
> commonly (in other words, "worth having your 'symbolic'
> mechanism for, because it is so commonly applicable") to
> branches offhand. Hence, JBF's suggestion to use "git pull"
> without using noiseword "parent" or "origin" feels very natural
> to me --- if there can be only one valid thing to say, why do
> you even have to say it?
Well, this is the question... Can you stipulate that there is
only _one_ valid thing to say? Wouldn't it be easier to generalize
the concept of "branch spec" to local "topic" branches as we do
now for remotes/. Wouldn't this allow people to have more freedom
at what and how they'd like to set their software dependencies?
The SCM industry seem to have generalized this with the
concept of a "branch spec".
> Because I do not understand what you would want "parent" for and
> why "git pull" is not sufficient,
Because it _implicitly_ defines the relationship. Nothing wrong
with that, but also allowing an explicit naming of the relationship,
as is currently done for remotes/, would give git much, much more
power to define even the most complicated software development
setup (locally).
As I pointed out before, "branch.<name>..{fetch,merge}" would
cover the "git-pull" case. "branch..<symbolic-ref>.{fetch,merge}"
should be illegal since it is the same as remotes/, and
"branch.<name>.<symbolic-ref>.{fetch, merge}" matches
"git-pull <symbolic-ref>".
> I cannot tell if this would
> help solving what you are trying to solve in a different way,
1) It would help solve it the proper way and,
2) it would give git the concept of "branch spec" universally, i.e.
local branches as well as remotes.
> but I suspect a useful thing to have might be a per-branch
> alias. For example, we could allow "git merge" without
> parameters to alias to "git merge origin/next" when you are on
> your 'next' and the same "git merge" could be aliased to "git
> merge origin/master" when you are on your 'master'.
Any why not solve the absolute general case forever, by
implementing what I have described above, and move on
to more interesting things?
Luben
next prev parent reply other threads:[~2007-01-01 8:20 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 [this message]
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=997672.38239.qm@web31814.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