Jeff King <peff@xxxxxxxx> writes:
> We have the problem now that new users do not necessarily understand the
> matching strategy, or why it is useful, and get confused. When we move
> to "simple", we may be switching to a world where the early part of the
> learning curve is more gentle for those users, but they eventually run
> across the steeper part when they want to adjust their workflow (i.e.,
> they will eventually learn about non-symmetric repo topologies because
> those are part of many useful workflows).
>
> But I think it's a good thing to push that part of the learning curve
> out, because:
>
> 1. Some people may stay in the centralized view their whole lives and
> never care.
>
> 2. It will make more sense to them, because they'll understand how it
> fits into what they're trying to do, rather than viewing it as an
> arcane and senseless default.
>
> There may be some confusion as people hit that learning point. I won't
> be surprised if we end up adding more advice.* messages in certain cases
> to guide people to adjusting their push.default. But I'm just as happy
> to wait until people start hitting the confusion point in practice, and
> we can see more clearly when that advice should trigger, and what it
> should say.
Oh, I agree with you that adding new support for triangular workflow
will not hurt the centralized folks. I was more interested about
helping the "fetch from here, push to there" people.
Centralized people do not have to configure anything for each branch
for "git push" to push their current branch to where they fetch from
and to the same name (you start building on their 'master', your
result go to their 'master', because as a centralized person, you
are part of 'them'). They have branch.$name.merge that names what
their $name branch merges with, and that is sufficient to decide to
which branch the result is to be pushed back.
With the "push.defaultTo = peff" to name what remote the "git push"
will push to, or even with the "branch.master.remotepush = peff" to
decide that per branch, would "fetch from here, push to there"
people have a way similar to what branch.$name.merge gives to the
centralized people to decide what branch is updated?
It almost seems to me that we may want to extend the semantics given
to the remote.$name.push refspecs. They are primarily for "perfect
all branches you are going to push out, and push them in one go with
'git push'" workflow, but if it is clear that you are not following
that (e.g. you are doing an equivalent of what the centralized folks
would do with "push.default = simple/upstream/current") and pushing
only the current branch, perhaps we should look at these refspecs to
see where the current branch goes?
In your case, 'refs/heads/master' would likely to go to
'refs/heads/master', and we could treat a missing remote.peff.push
an equivalent to having remote.peff.push = refs/heads/*:refs/heads/*
In a Gerrit user's case brought up by Michael Schubert in a message
earlier in the near-by subthread, 'refs/heads/frotz' would likely to
go to 'refs/for/frotz' and they can express it with something like
[remote "origin"]
url = ... ;# pushurl is the same or just s/git/ssh/;
fetch = refs/heads/*:refs/heads/*
push = refs/heads/*:refs/for/*
[push]
default = "???"
where "???" says "I push out only the currently checked-out branch;
figure out where it goes using remote.origin.push refspec".
Having to set both branch.$name.remotepush to name what remote this
branch should be pushed, and branch.$name.branchpush to name what
branch at the remote this branch should update with a push, and
doing so for each and every branch, sounds like an unnecessary
complexity.
--
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