[RFC] Reverting "git push logic change"?

The change introduced by 9e9b267 commit broke "correct" usage of
git push to push matching refs, to work around a problem
observed in a usage pattern on a shared repository.

I think I made a bad judgement in evaluating the scenario, and
made a bad change to "fix" a problem that did not exist.  I
apologize for having caused this confusion.

My conclusion after thinking about the problem again is that we
would be better of if we reverted that commit.  This message is
to make my intention clear, and solicit objections or comments
from the list.

The use case that prompted this change was this:

 - A shared repository is created by cloning Linus repository.
   This repository gets "origin" (then-current Linus master) and
   "master" (the same).

	$ git clone --naked \
          git://git.kernel.org/.../linux-2.6.git/ project.git

 - Two developers use this as their shared repository.  They
   first start out by cloning from it, do their development in
   their "master" branch and pushing back to the "master" branch
   of the shared repository.  Their workflow is:

	0. Clone it (once per developer):
        $ git clone ssh://pub.example.com/project.git/ work

	1. To make sure the developers are in sync:
	$ git pull ssh://pub.example.com/project.git/ ;# (a) or
	$ git pull origin			      ;# (b)

        2. His own development:
	$ edit;compile;test;git commit

	3. Pull from upstream, to avoid conflicts with it (only when needed):
	$ git pull git://git.kernel.org/.../linux-2.6.git/

	4. Push back the result to shared repository:
        $ git push ssh://pub.example.com/project.git/

With this workflow, in the two developer repositories, "origin"
branch is not really well maintained.  If "git pull origin" was
used with the remotes/origin file "git clone" initially gave
him, it would have kept track of the latest push into the shared
"master" closely, but if the explicit URL was used, "origin" of
the developer repository would have been left behind.

This is not problem as far as the correctness of the "master"
branch is concerned.  The fast-forward check when pushing into
the shared repository "master" branch prevents the two
developers from losing commits.  In other words, either way to
pull from the shared repository is legal/valid.

However, the push done in step 4. triggers the default "push all
matching refs" behaviour.  All three repositories have "origin"
and "master", which means this results in "origin" being updated
in the shared repository.  But one developer repository has a
stale "origin" while the other developer has an up-to-date
"origin".  This triggers a "not a fast forward" error, which
does not cause the push of "master" to fail, but still looks
worrisome.

I think the correct thing to do in this workflow is to simply
remove "origin" branch from the shared repository.  

Using or not using "origin" as a reference branch to keep track
of what was fetched from the shared repository is a matter of
personal taste for each developer, and there is no reason to
enforce either (1-a) or (1-b).  This means that the branch is
not maintained the same way in developer repositories, and there
is no point pushing into it --- there is no point to have
"origin" in the shared repository.

Once "origin" branch is removed from that shared repository,
then, either "push all matching refs", or "push 'master'
explicitly" would work well for these developers.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html