--- Junio C Hamano <junkio@xxxxxxx> wrote:
> Luben Tuikov <ltuikov@xxxxxxxxx> writes:
>
> > --- "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html