Jeff King wrote:
>   $ git clone
>   $ cd project
>   $ hack hack hack; commit commit commit
>   $ git tag -m 'something of note' my-tag
>   $ git remote add me
>   $ git config branch.master.remote me
>   $ git tag -m 'something of note'
>   $ git push master my-tag

Tags have nothing to do with branches, and it is illogical to respect
branch.* when pushing a tag.  You've illustrated a common case when
the user creates a tag on a specific branch and immediately pushes it.
 I would argue that optimizing our tools for this specific usecase
breaks the general case.  What if I create a branch on master, and
decide to push the tag after checking out implicit-push and doing some
work on it?  Does that not break user expectations?

In the "I push to the same place I pull from" (aka. single-remote)
case, there are never any problems and even "matching" works fine.
However, in the triangular workflow (aka. multiple-remote) case, you
must give git enough information about your workflow for it to DTRT.
I will argue that, in the above example, you have not configured git
for a multiple-remote case, and that you cannot expect it to DTRT
since you have supplied insufficient information.  As to how to
configure git for the general multiple-remote case:

Let us imagine that origin points to git/git.git (upstream), ram
points to artagnon/git.git and peff points to peff/git.git.  I fork
off from upstream and have various local branches that only have
corresponding refs in ram (say implicit-push).  Then, you fork off
from me, and have various local branches that only have corresponding
refs in peff (say implicit-push-next).  I have peff as a configured
remote, because I routinely review the changes you make to my fork.
In this case, I must have:

- push.default set to anything but matching, because matching makes no
sense in the multiple-remote scenario*.

- remote.default set to origin, because this is where I get new code
from for all branches.

- remote.pushdefault set to ram, because this is where I publish all
my refs to (whether branches or tags).  I might have local branches
that I will never publish, but that's a separate issue.  The point is
that all my tags will always be published here.

- branch.implicit-push.remote set to ram, because this is the correct
upstream for the implicit-push branch.

- branch.implicit-push-next.remote set to peff, because this is the
correct upstream for the implicit-push-next branch.

- branch.implicit-push-next.pushremote set to null**, because I will
never want to push this branch.

(Note that branch.implicit-push.pushremote is unnecessary because
remote.pushdefault takes care of that)

With these settings, git push will always DTRT when you specify
nothing, just a remote, or just a refspec.  Ofcourse, you can specify
both and be explicit (which is what we do now).  Does this make sense?
 Should we document this in gitworkflows.txt so that users know what
is expected of them when they move from a single-remote setup to a
multi-remote setup?

* I will definitely push for the deprecation of push.default=matching,
but I doubt we need to invent a new push.default.  current makes a lot
of sense to me personally.

** Yet to be invented.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to