Felipe Contreras wrote:
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> pushremote = github
> push = refs/heads/master
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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html