Junio C Hamano wrote: > Jeff King <p...@peff.net> 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.
In Git, there will always be a combination of switches which allows you to go the centralized workflow mode. We're focusing on expanding this list of switches, to free up distributed workflows into more possibilities. We're currently targeting problems that affect us everyday; the ones we've failed to notice. > 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. What about the branch.$name.pushRef, which was proposed earlier? They should be able to say, at a per-branch level, which branches to send for review (in Gerrit). > 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? Ah. > 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? I'd actually just go with the current syntax + per-branch overrides. Simple and serves the purpose: I don't think there'll be real usecases outside this. > 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/* I'll get to work on a patch that deems the configuration variable as not "necessary". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
