From: Luben Tuikov <ltuikov@yahoo•com>
To: Junio C Hamano <junkio@cox•net>, bfields@fieldses•org
Cc: git@vger•kernel.org, Shawn Pearce <spearce@spearce•org>,
Luben Tuikov <ltuikov@yahoo•com>,
Johannes Schindelin <Johannes.Schindelin@gmx•de>
Subject: Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
Date: Sun, 31 Dec 2006 19:29:22 -0800 (PST) [thread overview]
Message-ID: <59142.7095.qm@web31801.mail.mud.yahoo.com> (raw)
In-Reply-To: <7vwt47bjwa.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox•net> wrote:
> 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
next prev parent reply other threads:[~2007-01-01 3:29 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-31 23:47 [PATCH] Docs: update cvs-migration.txt to reflect clone's new default behavior bfields
2006-12-31 23:47 ` [PATCH] Documentation: update git-clone.txt for " bfields
2006-12-31 23:47 ` [PATCH] Documentation: update git-pull.txt " bfields
2006-12-31 23:47 ` [PATCH] Documentation: update glossary entry for "origin" bfields
2006-12-31 23:47 ` [PATCH] Documentation: remove master:origin example from pull-fetch-param.txt bfields
2006-12-31 23:47 ` [PATCH] Documentation: update tutorial's discussion of origin bfields
2007-01-01 0:35 ` [PATCH] Documentation: update git-pull.txt for clone's new default behavior Junio C Hamano
2007-01-01 1:12 ` J. Bruce Fields
2007-01-01 1:44 ` Junio C Hamano
2007-01-01 3:29 ` Luben Tuikov [this message]
2007-01-01 3:48 ` J. Bruce Fields
2007-01-01 5:13 ` Luben Tuikov
2007-01-01 5:45 ` J. Bruce Fields
2007-01-01 7:53 ` Luben Tuikov
2007-01-01 7:38 ` Junio C Hamano
2007-01-01 8:19 ` Luben Tuikov
2007-01-01 13:17 ` Theodore Tso
2007-01-01 23:56 ` Luben Tuikov
2007-01-02 1:08 ` Theodore Tso
2007-01-02 2:17 ` Luben Tuikov
2007-01-02 3:45 ` Junio C Hamano
2007-01-02 18:39 ` Luben Tuikov
2007-01-01 21:39 ` J. Bruce Fields
2007-01-01 21:40 ` J. Bruce Fields
2007-01-02 0:01 ` Luben Tuikov
2007-01-02 0:10 ` J. Bruce Fields
2007-01-02 0:57 ` Theodore Tso
2007-01-02 1:28 ` Luben Tuikov
2007-01-02 6:32 ` Junio C Hamano
2007-01-02 2:09 ` Luben Tuikov
2007-01-02 0:21 ` Junio C Hamano
2007-01-02 0:38 ` Jakub Narebski
2007-01-02 2:05 ` Luben Tuikov
2007-01-02 3:36 ` Junio C Hamano
2007-01-02 11:31 ` Jakub Narebski
2007-01-02 18:48 ` Luben Tuikov
2007-01-02 19:22 ` Jakub Narebski
2007-01-02 19:30 ` Junio C Hamano
2007-01-05 23:15 ` Luben Tuikov
2007-01-05 23:20 ` Junio C Hamano
2007-01-05 23:32 ` Junio C Hamano
2007-01-06 0:32 ` Luben Tuikov
2007-01-06 0:22 ` Luben Tuikov
2007-01-06 1:17 ` Junio C Hamano
2007-01-01 23:59 ` Luben Tuikov
2007-01-02 0:06 ` J. Bruce Fields
2007-01-02 0:12 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59142.7095.qm@web31801.mail.mud.yahoo.com \
--to=ltuikov@yahoo$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=bfields@fieldses$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
--cc=spearce@spearce$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox