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

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to