--- Junio C Hamano <junkio@xxxxxxx> wrote:
> Junio C Hamano <junkio@xxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html