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

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Jan 1, 2007, 03:29 UTC
Message-ID: <59142.7095.qm@web31801.mail.mud.yahoo.com>
In-Reply-To: <7vwt47bjwa.fsf@assigned-by-dhcp.cox.net>

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

Show 27 quoted lines

> Junio C Hamano <junkio@cox.net> writes:
> 
> > What we wanted to do ideally was to forbid "git pull" that does
> > not have explicit refspec from the command line, without
> > configuring branch.*.merge.  However this broke established
> > workflow of people who has remote.$origin.fetch configured to
> > list the remote branch to fetch explicitly; the merged branch
> > selection has always been "the first set of branches listed in
> > the configuration" and these peoples had their configuration
> > right without needing to have branch.*.merge at all.
> >
> > Unfortunately git is too flexible around this area.  
> >
> > We probably could somehow arrante the remote branches that came
> > from wildcarding not subject to the merge branch selection
> > logic, but honestly I am tired of looking at that code for now.
> 
> I am still tired of looking at the code, but I would rather 
> look at it now than having to still look at it next year.
> 
> How about doing this?  The difference this time around is that
> if you have non-wildcard refspec listed first, which usually
> is the case for people with established git workflow with
> existing repositories, we use the old-and-proven rule to
> merge the first set of refs.  An earlier round botched this
> completely by basing the logic on lack of branch.*.merge,
> which broke for many people.

Can we please instead revisit the "branch.<name>.remote" and "branch.<name>.merge" options?

What I'd really like to see and what really would be useful to me every day is if I could individually _address_ a "branch.<name>.remote" and "branch.<name>.merge" pair of options.

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.

Currently, the parent<-->child branch relationship only exists in paper: for example: git master is the parent for all my (local) branches, "git-upstream" is child of "next", "git-lt-work" is child of "git-upstream" and "git-home" is child of "git-lt-work", each one introducing its own customizations and changes. I currently do the pull/merge by hand, remembering the child/parent relationship and enforcing it manually by the strict pull/merge sequence I do.

Of course we shouldn't break existing usages like for example "git-pull . tag ...".

I can achieve the same thing using the "branch.*" options today, but I do "git-pull" and I'm not entrirely satisfied with that since in my head I know I'm doing a "parent->child" merge and would like to express that on the command line.

So this is something of a cross between the remotes/ and "branch.*" option.

For example "branch.<name>.<symbolic_ref>.fetch" and "branch.<name>.<symbolic_ref>.merge" would do the trick.

Then at prompt, I say "git-pull <symbolic_ref>" which will match local branch and symbolic name to whatever matches.

Of course, "branch..<symbolic_name>.*" would seem to be identical to remotes. We should disallow that by stipulating that a non-empty symbolic name imples non-empty branch name. "branch.<name>..*" would be identical to its current usage.

The point is that the symbolic name changes its designation depending on which is the current branch, and with a name like "parent" that makes sense.

    Luben