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