Re: Problem with a push

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 12, 2007, 01:35 UTC
Message-ID: <7vzm36lzua.fsf@assigned-by-dhcp.pobox.com>
In-Reply-To: <alpine.LFD.0.98.0706111727240.14121@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 12 quoted lines

> 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.

Show 6 quoted lines

>  - 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.