Re: [ITCH] Specify refspec without remote

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 13, 2013, 05:07 UTC
Message-ID: <CALkWK0=qigG40C7Htv0Yt6ZrgP+vgsauRe=2rWuAuq7UJ47rfw@mail.gmail.com>
In-Reply-To: <7vppy0hhk7.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 6 quoted lines

> 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.

Show 7 quoted lines

> 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.