Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

Felipe Contreras wrote:

Hm.  Some thoughts:

fetch and push aren't symmetric. By default fetches are batched: when you say 'git fetch', it fetches all the refs and uses the remote.<name>.fetch refspec to update the refs on your side. Now, I would argue that this is the correct design, because I rarely want to fetch just one ref (and that is broken, by the way: refs on my side aren't updated for some weird reason). The other reason this is correct is because fetching has nothing to do with local branches: how you _merge_ your remote branches to your local branches is entirely orthogonal to the issue (and that is controlled by branch.<name>.merge).

Now, push is a different ball game altogether. There are people who do batched pushes (push.default = matching has been the default for 8 years now). However, the support for a batched push in a triangular workflow is very limited: I can't say git push master hot-branch pickaxe-doc, and expect them to go to the right remotes (this idea has already been discussed and rejected). Back to your patch: if you want to support batched pushes to map refs correctly, you should write a patch for remote.<name>.push. It has a very valid usecase too: there are people who use Gerrit and they shouldn't have to do git push <name>:refs/for/<name> every single time. Neither should they have to configure each branch.<name>.push. The ref-mapping is an inherent property of the remote, not of the local branch. And branch.<name>.merge is entirely orthogonal to ref-mapping, as I already explained.

That said, I think the concept of a downstream can be useful. I have branch.hot-branch.remote set to origin, and branch.hot-branch.pushremote set to ram. Now, I push some changes: my prompt still says > (indicating unpushed changes), and this is very annoying. I would definitely like git to be able to recognize that I'm ahead of upstream, but in-sync with my downstream. So, your branch.<name>.push should probably be named branch.<name>.downstreamref and be used only for informational purposes (@{d} and git status)? Wait, why do we need it at all? Is there something that we cannot infer from a proposed remote.<name>.push? Why will we ever need to override that refspec mapping with a local branch configuration?