Steffen Prohaska <prohaska@xxxxxx> writes:
> 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.
-
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
