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

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Jan 1, 2007, 05:13 UTC
Message-ID: <951491.40207.qm@web31807.mail.mud.yahoo.com>
In-Reply-To: <20070101034825.GD15537@fieldses.org>

--- "J. Bruce Fields" <bfields@fieldses.org> wrote:

Show 8 quoted lines

> On Sun, Dec 31, 2006 at 07:29:22PM -0800, Luben Tuikov wrote:
> > I.e. I'd like to say "git-pull parent" or "git-pull parents"
> > in such and such branch, and this would pull the designated
> > parent(s) for the current branch.  But if I'm in a different
> > branch (of the same repo) then the meaning of "parent" changes
> > accordingly.
> 
> 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.

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

(Since this is what is actually ment by the "branch.*" options.)

> Am I misunderstanding the proposal?

I did give an example of usage in my email to which you replied.

Basically I'd like to extend the concept of "branch spec" locally.

> And is there any reason why your proposal conflicts with Junio's?

Yes. Beating on a dead horse. "branch.*" options simply do not cut it. We can either get rid of them completely or extend them to where they are actually useful. Globbing resolution is secondary to resolving the methodology.

HTH,
    Luben