Re: pull/push inconsistencies

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

That's my expectation and I am a bit surprised if it doesn't.

The standard answer is not to push into a live repository without understanding what you are doing.

I've been debating this myself, but I do not think of a good canned configuration to satisfy different workflows.

 - Central repository setup a la CVS would want to:

	$ git clone $remote

   would create

	[remote "origin"]
        	url = $remote
                pull = refs/heads/*:refs/remotes/origin/*

   and would want to rely on the "only-fast-forward" safety to
   push into the corresonding branch.

	$ git push

   would push only corresponding branch, so there is no need for
   configuration.

   However, this is usually good only for the CVS-style shared
   central bare repository.

 - When using multiple private repositories, hopping between
   mothership and satellite, often the arrangement to allow
   fetch and push be symmetrical is desired:

	satellite$ git clone $mothership

   would create:

   	[remote "origin"]
        	url = $mothership
                pull = refs/heads/*:refs/remotes/origin/*

   on the satellite.  But if mothership could push into
   satellite, you would also want to have

	[remote "satellite"]
                url = $satellite
                push = refs/heads/*:refs/remotes/origin/*

   to make "git push satellite" run on mothership and "git fetch
   origin" run on satellite be equivalent.

   In this workflow, it is clear that a push from the mothership
   alone would not affect the working tree of the satellite; in
   fact, pushing into tracking branches from the mothership is
   arranged to mirror fetching into tracking branches from the
   satellite, with the explicit purpose of not affecting the
   working tree of the satellite, so there is less room for
   confusion.

   However, we cannot make this the default, which would break
   the traditional CVS-style shared central repository

 - A developer who publishes to his public distribution point
   (bare):

	public$ git clone --bare $my_private_repo

        private$ git push $public

   This pushes the matching refs between the two, which is the
   right thing, without any configuration.  You would not
   accidentally publish newly created throwaway branches you
   used while working inside the private repository.

Unfortunately, historically "git-push" was publisher's tool (the last workflow was the primary target). Later central bare repository support was also documented. The second workflow is not very well supported.

And pushing into live repository using 'matching refs' is almost always a mistake, unless the user knows what he is doing.

git-push without parameters and configuration pushes matching branches. This has been true from day one. Again, I think we should be able to make this safer so that "git-push" in cloned repository would do something more restricted (perhaps limiting to refs/heads?), but I do not think of a universally acceptable canned configuration.

Yes, git is distributed and perhaps the expectation to be able to "git push" without saying where to and what to push is coming from some centralized system mindset. If somehow we can disable "git push" before a sensible refspecs are configured, that would be an improvement for new users, but the "push matching refs" behaviour is very handy for already established workflows of people who publish things.

When pushing into your public distribution point, which does _NOT_ have remotes/* hierarchy by definition, what will match between your private working repository and your public distribution point are heads/ and tags/ and all goes well. You do not want to accidentally push your new throwaway branches.