删除名称错误的 git 分支 [英] Deleting a badly named git branch

查看:34
本文介绍了删除名称错误的 git 分支的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道这不是严格意义上的编程问题,但它与 git 相关.我不小心在 git 中创建了一个名为 --track 的分支(合并远程分支时选项顺序错误)

常规命令不起作用:

git branch -D "--track"

我试图用引号和反斜杠进行转义,但都不起作用.

有什么想法吗?

解决方案

你尝试了吗

git branch -D -- --track

?--"通常是以下内容不是一个选项,无论其名称如何"的约定

<小时>

来自Unix 编程艺术",部分命令行选项":

<块引用>

将双连字符识别为停止选项解释并按字面处理所有以下参数的信号也是惯例.

您会在其他(非必需的 Unix 相关)CLI(命令行界面)中找到该约定,例如 cleartool:

<块引用>

如果 nonoption 参数 以连字符 () 开头,您可能需要在它前面加上双连字符参数,以防止它被解释为一个选项:

cleartool rmtype -lbtype -- -temporary_label-

P18(具有宏处理能力和特殊支持的快速灵活的文件预处理器对于国际化)也提到了这一点,并很好地描述了该约定背后的一般思想:

<块引用>

传递给命令的所有选项参数都以一个连字符开头.
所有选项参数(如果有)必须在所有非选项参数之前.
可以使用双连字符来表示选项参数的结束,如果非选项参数以连字符开头,这很有用.使用双连字符终止选项参数列表适用于所有命令,即使是那些不带任何选项参数的命令.

用 ruby​​ 编写的 OptionParser 工具也非常清楚地列出了它:*

选项解析终止

<块引用>

约定双连字符是停止选项解释和从字面上读取命令行上剩余语句的信号.所以,一个命令,如:

 app -- -x -y -z

<块引用>

不会看到"三个模式标志.相反,它们将被视为应用程序的参数:

 #args = ["-x", "-y", "-z"]

<小时>

注意:有时需要三个破折号而不是两个,尤其是当 CLI 严格遵循 Gnu 选项样式时:

<块引用>

Gnu 风格的命令行选项提供对选项词(或关键字)的支持,但仍保持与 Unix 风格选项的兼容性.
这种样式的选项有时称为 long_options,Unix 样式的选项称为 short_options.
通过在 long_options 前面加上两个破折号来保持兼容性

类似于 Unix 风格的双连字符 '--',Gnu 风格有一个三连字符 '---' 表示选项解析被停止并将剩余的文本视为参数(即从命令行逐字读取)

所以...如果 ' -- ' 不够用(应该用 Git 命令),试试 ' --- '

I know this isn't strictly a programming question, but it is related to git. I accidentally have created a branch in git called --track (I got the order of options wrong when merging a remote branch)

The regular command doesn't work:

git branch -D "--track"  

I have tried to escape with quotes and backward slashes, however neither work.

Any ideas?

解决方案

Did you try

git branch -D -- --track

? the "--" is usually the convention for "what follows is not an option, whatever its name"


From "The Art of Unix Programming", section "Command-Line Options":

It is also conventional to recognize a double hyphen as a signal to stop option interpretation and treat all following arguments literally.

You will find that convention in other (not necessary Unix-related) CLI (Command Line Interface) like cleartool:

If a nonoption argument begins with a hyphen () character, you may need to precede it with a double-hyphen argument, to prevent it from being interpreted as an option:

cleartool rmtype -lbtype -- -temporary_label- 

The P18 (a fast and flexible file preprocessor with macro processing capabilities and special support for internationalization) mentions that also and gives a good description of the general idea behind that convention:

All option arguments passed to the commands start with a single hyphen.
All option arguments (if any) must precede all non-option arguments.
The end of the option arguments may be signaled using a double hyphen, this is useful if a non-option argument starts with a hyphen. Terminating the list of option arguments with a double hyphen works for all commands, even those that don't take any option arguments.

The OptionParser tool written in ruby also lays it out quite plainly:*

Option Parsing Termination

It is convention that a double hyphen is a signal to stop option interpretation and to read the remaining statements on the command line literally. So, a command such as:

 app -- -x -y -z

will not ‘see’ the three mode-flags. Instead, they will be treated as arguments to the application:

 #args = ["-x", "-y", "-z"]


Note: sometimes, it takes three dashes and not two, especially when the CLI follows strictly the Gnu options styles:

The Gnu style command line options provide support for option words (or keywords), yet still maintain compatibility with the Unix style options.
The options in this style are sometimes referred to as long_options and the Unix style options as short_options.
The compatibility is maintained by preceding the long_options with two dashes

Similar to the Unix style double-hyphen ’--’, the Gnu style has a triple-hyphen ’---’ to signal that option parsing be halted and to treat the remaining text as arguments (that is, read literally from the command line)

So... if ' -- ' is not enough (it should be with Git commands), try ' --- '

这篇关于删除名称错误的 git 分支的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆