Re: git push bug?

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 20, 2007, 08:29 UTC
Message-ID: <5513C211-DE33-411C-8EE6-2259B41DC3EA@zib.de>
In-Reply-To: <Pine.LNX.4.64.0710182258000.25221@racer.site>

On Oct 18, 2007, at 11:58 PM, Johannes Schindelin wrote:

Show 24 quoted lines

>
> On Thu, 18 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 18, 2007, at 6:21 PM, Johannes Schindelin wrote:
>>
>>> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
>>>
>>>> Seems like it is a bit too easy to make mistakes here. Why can I  
>>>> delete
>>>> a branch with :linus but not create one with linus:linus?
>>>
>>> I wonder why you bother with the colon at all.  Just
>>>
>>> 	git push <remote> linus
>>>
>>> and be done with it.  The colon is only there to play interesting  
>>> games,
>>> not something as simple as "push this branch" or "push this tag".
>>
>> But you need a full refspec starting with 'refs/heads/' if you  
>> want to
>> create a new branch on the remote side.
>
> No.  Not if the name is the same on the local side.

You're right. The documentation of git-send-pack says what you're saying:

''' When one or more <ref> are specified explicitly, it can be either a single pattern, or a pair of such pattern separated by a colon ":" (this means that a ref name cannot have a colon in it). A single pattern <name> is just a shorthand for <name>:<name> '''

Here it says that <name> is a shorthand for <name>:<name>. An later it states

'''
If <dst> does not match any remote ref, either
    * it has to start with "refs/"; <dst> is used as the destination  
literally in this case.
    * <src> == <dst> and the ref that matched the <src> must not  
exist in the set of remote refs; the ref matched <src> locally is  
used as the name of the destination.
'''

If <src> == <dst> then <dst> will be created even if it didn't exist.

I think the current implementation though is a bit different. It will created a new branch for a colon-less refspec, that is

    git push origin work/topic

will create a new ref on the remote. But

    git push origin work/topic:work/topic

will _not_.

Until you corrected me, I believed that new branches will never be created on the remote side unless a full ref is used. That is I expected that only

    git push origin refs/heads/work/topic

would work.

I thought this would be another safety net -- kind of a reminder not to push the wrong branch by accident.

I still like the idea, but apparently git didn't ever support what I thought it would.

Maybe adding some command line flags making the different tasks explicit could help:

     git push --create origin work/new-topic
     git push --delete origin work/old-topic
     git push --non-standard origin refs/funny/ref

We already have similar flags

     --all: all branches
     --tags: all tags
     --force: force non-fast-forward.

I haven't fully thought this through. Maybe I'll come up with a patch later.

	Steffen