Johan Herland <jo...@herland.net> writes: > I haven't yet dug deep enough to figure out an obvious failure mode > (and I probably should not have sent this email until I'd found one), > but I wonder if we'd be better off forcing the $remote and $remote_ref > configuration for a given branch to appear as more of a single unit.
That sounds sensible. I could see perhaps we would want to require, for branch.*.push to be effective, branch.*.pushremote must be set (honestly speaking, branch.*.push is not my itch and I'd probably be happier if we didn't add it in the first place, though ;-). > What if, when setting up tracking for a given branch, we immediately > specified its complete pull and push targets? > > For example, when in a centralized workflow (e.g. push.default = > upstream) and we're checking out local branch foo from origin's foo, > we could set up the following configuration [1]: > > [branch "foo"] > pull = origin/foo > push = origin/foo They should both be refs/heads/foo, as these are meant to name the name in _their_ repository. I see what you are saying, but the behaviour you want happens without branch.foo.push, and the addition may be redundant. I do not immediately see what it is buying us. Other than that when the user stops being centralized and starts to push to his own publishing repository, branch.*.push needs to be removed in addition to flipping push.default from upstream to current, that is. > In a triangular workflow (assuming we had configuration to specify > such, and also a default push remote), we could then instead set up > the following config: > > [branch "foo"] > pull = origin/foo > push = my_public/foo Again, these are both refs/heads/foo. > This leaves no ambiguity for even the most novice user as to the pull > and push targets for a given branch, and it's also easy to change it, > either by editing the config file directly, or by using hypothetical > commands: > > git branch foo --pulls-from=origin/bar > git branch foo --pushes-to=other_repo/foo But you need to do that for _all_ branches when you acquire your own publishing point; isn't that a rather cumbersome usability glitch? > Obviously, specifying the remote and/or refspec on the command-line > would still override, as it does today, but for the argument-less > forms of "git pull" and "git push", the hierarchy of options and > defaults being consulted to figure out $remote and $remote_ref would > be small and easily understandable. Not really. In addition to "you need to run around and change configuration for all branches" issue, you can never do push.default=matching, if you always set branch.foo.push and made it stronger than push.default, no? -- 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
