git - Which characters are illegal within a branch name?

ID : 10191

viewed : 34

Tags : gitbranchnaminggit

Top 5 Answer for git - Which characters are illegal within a branch name?

vote vote

90

Naming rules for refname:

Git imposes the following rules on how references are named:

  1. They can include slash / for hierarchical (directory) grouping, but no slash-separated component can begin with a dot . or end with the sequence .lock.

  2. They must contain at least one /. This enforces the presence of a category like heads/, tags/ etc. but the actual names are not restricted. If the --allow-onelevel option is used, this rule is waived.

  3. They cannot have two consecutive dots .. anywhere.

  4. They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 DEL), space, tilde ~, caret ^, or colon : anywhere.

  5. They cannot have question-mark ?, asterisk *, or open bracket [ anywhere. See the --refspec-pattern option below for an exception to this rule.

  6. They cannot begin or end with a slash / or contain multiple consecutive slashes (see the --normalize option below for an exception to this rule)

  7. They cannot end with a dot .

  8. They cannot contain a sequence @{.

  9. They cannot be the single character @.

  10. They cannot contain a \.

On top of that, additional rule for branch name:

  1. They cannot start with a dash -

Thanks to Jakub Narębski, the man page for git check-ref-format has more details.

vote vote

84

The accepted answer and the man page already explain which rules apply to Git branch names.

In the Git source code, the refname_disposition array is used to determine how to handle various characters in refnames. The indexes in the array correspond to ASCII codes and the values indicate how the ASCII characters are handled.

/*  * How to handle various characters in refnames:  * 0: An acceptable character for refs  * 1: End-of-component  * 2: ., look for a preceding . to reject .. in refs  * 3: {, look for a preceding @ to reject @{ in refs  * 4: A bad character: ASCII control characters, and  *    ":", "?", "[", "\", "^", "~", SP, or TAB  * 5: *, reject unless REFNAME_REFSPEC_PATTERN is set  */ static unsigned char refname_disposition[256] = {     1, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,     4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,     4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 2, 1,     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 4,     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 0, 4, 0,     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 4, 4 }; 

Since 4 means that the corresponding ASCII character is not allowed inside branch names, there are 39 disallowed characters. The disallowed characters are ASCII control characters (ASCII codes < 32), the printable characters : ? [ \ ^ ~ and the whitespace/tab character.

3 more characters require some conditions to be met (see doc comment):

  • .: Two subsequent dots are forbidden.
  • {: The substring @{ is forbidden.
  • *: Reject unless REFNAME_REFSPEC_PATTERN is set.

The null byte terminates the branch name and / creates a new directory hierarchy for the branch. Therefore, branch names cannot end with a slash. For example git checkout -b 'a/b/c' will create the corresponding directory structure under .git/refs/heads

Note that UTF-8 characters can be used in branch names:

$ git checkout -b $'\xCE\xA9' Switched to a new branch 'Ω' 
vote vote

79

As an addition, care must be taken if you consider to use the dollar sign $ character. git branch pew$ign will create pew. In order to create a branch that has $ within it the whole name should be wrapped in quotes: git branch 'pewSign'. Ideally you should avoid to use the symbol whatsoever.

vote vote

69

vote vote

56

I had same exception in a custom binding scenario. Anybody using this approach, can check this too.

I was actually adding the service reference from a local WSDL file. It got added successfully and required custom binding was added to config file. However, the actual service was https; not http. So I changed the httpTransport elemet as httpsTransport. This fixed the problem

<system.serviceModel> <bindings>    <customBinding>     <binding name="MyBindingConfig">        <textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"         messageVersion="Soap11" writeEncoding="utf-8">         <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"           maxBytesPerRead="4096" maxNameTableCharCount="16384" />       </textMessageEncoding>        <!--Manually changed httpTransport to httpsTransport-->       <httpsTransport manualAddressing="false" maxBufferPoolSize="524288"         maxReceivedMessageSize="65536" allowCookies="false" authenticationScheme="Anonymous"         bypassProxyOnLocal="false"          decompressionEnabled="true" hostNameComparisonMode="StrongWildcard"         keepAliveEnabled="true" maxBufferSize="65536"          proxyAuthenticationScheme="Anonymous"         realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"         useDefaultWebProxy="true" />     </binding>   </customBinding>  </bindings>  <client>   <endpoint address="https://mainservices-certint.mycompany.com/Services/HRTest"     binding="customBinding" bindingConfiguration="MyBindingConfig"     contract="HRTest.TestWebserviceManagerImpl" name="TestWebserviceManagerImpl" /> </client>   </system.serviceModel> 

References

  1. WCF with custombinding on both http and https

Top 3 video Explaining git - Which characters are illegal within a branch name?

Related QUESTION?