Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 30, 2007, 19:19 UTC
Message-ID: <7vejfcl8aj.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <52171BF7-50E2-473E-A0BD-CB64D38FD502@zib.de>

Steffen Prohaska <prohaska@zib.de> writes:

Show 15 quoted lines

> On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
>
>> It simply is insane to make this strange rule 10/10 introduces
>> the default behaviour.  It is too specific to a particular
>> workflow (that is, working with a shared central repository,
>> having many locally tracking branches that are not often used
>> and become stale, and working on only things to completion
>> between pushes).
>
> I don't think its very strange behaviour if you see it in the
> light of what the user wants to achieve. We are talking about
> the case were only fast forward pushes are allowed. So, we
> only talk about a push that has the goal of adding new local
> changes to the remote. The user says "git push" and means
> push my new local changes to the remote.

If you want to push a specific subset of branches, you should not be invoking the "matching refs" to begin with. And breaking the "matching refs" behaviour is not the way to fix it.

You can rewind a wrong branch by mistake locally and run push. With your change you would not notice that mistake.

        $ git checkout bar
        $ work work work; commit commit commit
	$ git checkout test
        $ git merge bar
	... integrate, build, test
        ... notice that the tip commit of bar is not ready
        $ git checkout foo ;# oops, mistake
        $ git reset --hard HEAD^
	$ git push

If you checked out foo instead of bar by mistake at the last "git checkout" step like this, your change will make 'foo' an ancestor of the other side of the connection, and push silently ignores it instead of failing.

Also, the behaviour is too specific to your workflow of working on things only to completion between pushes. If you work a bit on branch 'foo' (but not complete), and work much on branch 'bar', 'baz', and 'boo' making all of them ready to be published, you cannot say "git push" anyway. Instead you have to say "git push $remote bar baz boo".

This discourages people from making commits that are not ready to be published, which is a very wrong thing to do, as a major selling point of distributed revision control is the dissociation between committing and publishing.

You work and commit freely, and at any point some of your branches are ready to be published while some others aren't. Inconvenience of "matching refs" may need to be worked around. I liked your "current branch only", with "git push $remote HEAD" (I presume that "remote.$remote.push = HEAD" and "branch.$current.remote = $remote" would let you do that with "git push"), exactly because the way it specifies which branch is to be published is very clearly defined and easy to understand. This "matching but only ff" does not have that attractive clarity.