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

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Jan 1, 2007, 08:19 UTC
Message-ID: <997672.38239.qm@web31814.mail.mud.yahoo.com>
In-Reply-To: <7vfyav8ae1.fsf@assigned-by-dhcp.cox.net>

--- Junio C Hamano <junkio@cox.net> wrote:

Show 16 quoted lines

> 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.

Show 13 quoted lines

> >> 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/.

Show 8 quoted lines

> 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.

Show 5 quoted lines

> 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