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

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Jan 1, 2007, 07:53 UTC
Message-ID: <452383.57759.qm@web31813.mail.mud.yahoo.com>
In-Reply-To: <20070101054536.GG15537@fieldses.org>

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

Show 9 quoted lines

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

Show 5 quoted lines

> 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