Re: Problem with a push

Linus Torvalds [off-list ref] writes:

That said, I don't think that's necessarily the right answer in the longer 
run. It's how git people do things, but it's not necessarily the *best* 
way of doing things. I think the better solution in the longer term is to 
simply improve how "git push" works:

 - we should probably do the same kinds of .git/config file entries for 
   pushing as we do for fetching, and just get rid of the old implicit 
   model, and instead have a nice refspec pattern model for what gets 
   pushed instead.

   I _think_ the refspec cleanup work by Daniel makes this something we 
   can almost already do. Daniel?

That has already been there long before Daniel's patches.

 - we should also likely have some way to specify what happens when you 
   push into a branch that is currently checked out and has a working tree 
   associated with it.

   This was briefly discussed a few weeks ago, but nobody cared enough, I 
   suspect.

That actially is in the todo:TODO for some time.  Just have been
too busy to look into it.

anyway, I think the _proper_ thing to do would be to associate each 
[remote] entry in the config file with a "push" refspec pattern, the way 
we do for "fetch" already.

I do not think that is enough.  A sane thing if we were doing
"git push" from scratch and there is no existing user's fingers
to re-train, would be:

 * "git-push" without anything will default to "git-push
   origin"; this has been working for a long time.

 * "git-push $remote" when there is [remote] refspec config use
   that refspecs, not "matching refs"; this also has been
   working for a long time.

 * We would want to change git-push so that "git-push $remote"
   will _NOT_ default to 'matching refs'.  We keep that
   'matching refs' behaviour only when the other end is a bare
   repository.

 * For "git-push $remote" to a non-bare repository, that does
   not have [remote] push refspecs, we probably would want to
   change the default to refuse operation, or push only
   'matching heads' (as opposed to 'matching refs').

Alternatively, we could teach "git clone" and "git remote add"
to add push refspec in the config, and keep the 'matching refs
if there is no push refspec in the config' behaviour.

However, the push refspec needs to be different depending on the
bareness of the remote, and I do not see a good way to arrange
this.

"git clone" does communicate with the remote, so theoretically
we ought to be able to do that, but there currently is no way to
indicate bareness of the remote to the client.

"git remote add" by default does not even communicate with the
remote, so without telepathy that is even more cumbersome to
arrange than "git clone" case.