Subject: Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior

From: Luben Tuikov <[email-masked]>
Date: Mon, 1 Jan 2007 00:19:45 -0800 (PST)

--- Junio C Hamano <[email-masked]> wrote:
> Luben Tuikov <[email-masked]> writes:
> 
> > --- "J. Bruce Fields" <[email-masked]> 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