Junio C Hamano wrote:
> When pushing into other kinds of repositories (e.g. you can update
> some but not all of the branches, or you want to touch only some of
> them and not others even if you have enough privilege to update any
> of them) or when you do not "batch" and push out one branch as work
> on it is done, while other branches that you would eventually
> publish are still not ready, "matching" is not for you.

I agree that we need to get a "batching" push.default corresponding to
"matching" for multiple-remote setups.  However, I think we should
hold it off until my implicit-push patch is finished.  After using it
for a few days, I'll get a good idea about what this new push.default
setting should look like.

> If "implicit-push" branch at "ram" is updated by other people and
> you may have to pull back from, you would need this for "git pull"
> (without arguments) while on that branch, I guess.  But I got the
> impression from your scenario that "ram" won't be updated by anybody
> but you.
> So I am guessing that this may not be needed.

In my opinion, it is a fundamental mistake to have more than one
person working on a branch.  There is one exception to this rule: it
is alright when there are only two people working on it, and one of
them is a "reliable fast-forward-only read-only upstream".  Let me
illustrate this with an example: I sometimes find myself working on
the master branch of git.git (fetch from origin: git/git.git, publish
to ram: artagnon/git.git).  This is because origin/master is an
"reliable fast-forward-only read-only upstream" (read-only in the
sense that it can only be updated with a git fetch).  My interaction
with it is limited to 'git rebase origin/master' on the master branch.
 I will never find myself manipulating it, and the rebase will never
fail unless my patches conflict with the new upstream.

As to why the setting is needed: I often work on more than one device*,
and I suspect a lot of people do this today.  I always fetch all
changes on my private branches before beginning work, unless I want to
end up in a confusing mess (I often rewrite history).

> This becomes necessary only if you use push.default set to "current"
> (or "upstream").  If you mistakenly say "git push" (no other
> arguments), without this configuration you will end up pushing the
> branch out.

Right.  The objective is to get 'git push' to _always_ DTRT.

> It may be that adding push.default=current-but-do-not-create-anew
> could help.  It is a cross between 'matching' and 'current', to say
> "consider pushing out the current one, but only when the other side
> already has one", and may help people who do not "batch".

Hm.  I would argue that exploding push.default options is unhealthy,
and that we should move towards thinking of more fine-grained control
with different orthogonal options.  I'll first do it for pull
(autostash has been in progress for some time); then we can port the
relevant options to push.

* I still haven't made much progress on a design for config-sharing.  I
think I'm missing something big.
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