Re: [RFC/PATCH] push: introduce implicit push

Junio C Hamano wrote:

I _thought_ "matching" was a good scapegoat to blame current user expectations on. However, it's okay if you think that we're misplacing the blame. As long as we can agree that user expectations are aligned with "choosing the remote based on the current branch", we're good. Let's not waste time attempting to dissect the reason for this.

Note that I'm not married to the interface I'm proposing: we can always have a git branch --set-destination-to, corresponding to git branch --set-upstream-to. I'm not sure what interface to come up for tweaking remote.pushdefault though (since we have deemed that a remote.default counterpart is unnecessary, we've never really thought about the problem).

branch.*.pushremote is a very new feature, and I doubt it's even available to users yet (distribution package); therefore there is no meaning set-in-stone that we cannot change quickly. If you think about it, it's completely illogical for branch.* options to depend on the state of the worktree; I really think we should push for them to be inherent branch properties: we can update the documentation accordingly, if we agree on this.

I think the main point of disagreement is that I'm in favor of
respecting logic, while you're in favor of respecting user
expectations set by (what we acknowledge now as) historical mistakes.
 I'm not saying that we should _not_ respect user expectations, but
rather that we should find some way to mould our users' expectations
to align with the logical choice without causing unpleasantness.

Okay, no problem. Just so we're clear: the "guess destination magic" will only kick in when all the refspecs specified are either tags or branches, and are missing the :<dst> counterpart. So, git push master +implicit-push should work just fine.

This is logically incorrect: you're essentially making branches and tags equivalent, while this is clearly not the case. Will I ever create "throwaway tags" just on my local machine for ease of working, that I desire not to publish anywhere? Now, replace "tags" with "branches" in that sentence, and you have a completely different answer. Will I ever want to send certain specific "tags" to a special destination (for review, for instance)? Again, "branches" gives you a different answer. Can I attach properties to tags? Are there tag.* variables that I can set? Why, then, do branches have these variables? Because they're not tags! The way we work with branches is completely different from the way we work with tags.

Let me try to drive this point in even harder:

My local clone is never one repository, but a "composite repository" containing object stores from multiple remotes mixed in. The fantastic thing about git is that I can use the same worktree/ index/ local refs to work with this composite, as if it were a single repository. However, I need a way to sort through this mixed object store/ multiple remotes madness: and for this, I have different remote refs, and local branch specific configuration variables. Again, I don't think of my repository as a whole, but rather as a collection of related branches that each have a specific source and destination. I do _not_ have one global source, or one global destination: that's just the two-remote case, and git allows me to have N remotes in the general case. What I meant by "triangular workflows" was not the reduced case of a repository-wide triangle, but about many little triangles associated with every branch.

What is the practical application for all this?  What if I always want
to send some specific branches to a different destination (say Gerrit
review, or my friend's "integration server")?  What if I never want to
publish some branches (say they contain sensitive information such as
private keys)?  What if my upstream gave me write access to some
specific branches (in which case, I don't want to push those branches
to my usual "fork destination")?  Why are you proposing to
artificially limit the implicit-push topic to not support these cases?
 They're not special or fringe cases, but the general case that git
was always designed for.

Moreover, in your attempt to design a compromise, you're inventing a different precedence order! Wait a minute: why should we compromise in the first place? We're not an old enterprise trying to satisfy a myopic client specification for a living; developing git is our full-time hobby (today is a Sunday, by the way), and we should not build something that we're less-than-elated with. In my proposal, the precedence order branch.<name>.pushremote, remote.pushdefault, branch.<name>.remote, remote.default, origin, remains the same: we just want to change which branch that <name> refers to. In my opinion, it is a much more subtle change than the entirely new precedence order that you're inventing.