Re: [PATCH 6/6] push: honor branch.*.push

[Junio C Hamano <gitster@pobox.com>]

Johan Herland <johan@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?