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

From: Luben Tuikov <[email-masked]>
Date: Sun, 31 Dec 2006 23:53:53 -0800 (PST)

--- "J. Bruce Fields" <[email-masked]> wrote:
> On Sun, Dec 31, 2006 at 09:13:49PM -0800, Luben Tuikov wrote:
> > 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...
> 
> Wouldn't it do what you want if by default "git branch new" and "git
> checkout -b new" set branch.* options that pointed at the "parent"
> branch?

Technically yes.  Presentationally no.

> The only reason I can see to require the extra bit of syntax ("git-pull
> parent" instead of "git-pull") is if for the same branch you expect to
> sometimes pull from one source and sometimes from another, and the pulls
> from those various sources are common enough that it's worth defining
> some shortcuts for more than one of them.

Exactly.

> I can imagine sometimes doing that.  (E.g. if you pull into your master
> branch from upstream and from local topic branches.)  But in that case
> having to give the remote and branch name explicitly doesn't seem so
> bad.

Basically I want to _name_ the dependency, instead of having it be
implicit.  One can extend that dependency, in more complicated
topic branch relationship, where for example, C extends B, B extends
A, A extends master, but B' also extends A, consider B' a "version"
of the extension which B implements.  This is of course a trivial
example and more complicated ones exist.

Naming the dependency would give git greater coverage when it needs
to implement complicated source development environments and code
relationship. IOW, it is the way to go.  Having a single implicit
dependency is just a crutch, half-way there.

Or, one can look at it in a different way, extending the
remote/ functionality as is, but instead of being remote-pulls-
into-local, extending for local pulls into local.

I.e. the remote relationship is named,  I'd like to extend
this locally as well.

Consider the examples of "branch.<name>.<symbolic_ref>.{fetch, merge}"
I gave in a previous email in this thread.

     Luben