请在提交问题之前回答以下问题。谢谢!
您正在使用的Go版本是什么( go version
)?
go version go1.10.3 linux/amd64
您正在使用的git-codereview版本是什么?
这个问题是否在最新版本中重现?
是的。
您正在使用什么操作系统和处理器架构( go env
)?
GOBIN=""
GOCACHE="/home/vimeo/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/vimeo/godep"
GORACE=""
GOROOT="/home/vimeo/go"
GOTMPDIR=""
GOTOOLDIR="/home/vimeo/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build902163312=/tmp/go-build -gno-record-gcc-switches"
您做了什么?
按照其README克隆了 x/image
仓库:
$ git clone https://go.googlesource.com/image $GOPATH/src/golang.org/x/image
$ cd $GOPATH/src/golang.org/x/image
为Go的Gerrit系统注册并设置cookies(我之前已经设置过了,技术上来说。)
按照 the documentation 安装了 git-codereview
:
$ go get -u golang.org/x/review/git-codereview
按照文档创建了一个新分支进行工作,并进行了更改:
$ git checkout -b newbranch
$ vim whatever.go
$ git add whatever.go
$ git codereview change
您期望看到什么?
我期望 git codereview change
能够向提交信息中添加一个 Change-Id:
行。
您实际看到了什么?
它没有向提交信息中添加 Change-Id:
。
解决方法/可能重要的额外信息
如果我不遵循文档,而是使用 git checkout -b newbranch
而不是 git codereview change newbranch
,那么它确实会像要求那样添加 Change-Id:
行。但这与golang.org上的官方文档所说的不符。值得一提的是,这种情况也出现在 x/image repo; I haven't tried the official
go` 仓库上。
9条答案
按热度按时间vatpfxk51#
我一直以来在使用
git codereview change <branchname>
来处理新补丁,据我所知,这是推荐的方法。不确定git checkout -b newbranch
是如何出现在文档中的,但我相当确定去年它并不在那里。我认为它是在最近的提交指南重写中添加的。调查为什么它被改变可能是有用的。
vuktfyat2#
看起来它是在巨大的重写提交中添加的:a3d8326
似乎没有在提交信息或审查评论中包含任何原因,所以我不确定它能解释多少。
vjrehmav3#
CC @rasky
pw9qyyiw4#
对我有效。当
$EDITOR
首次打开时,您看不到Change-Id
行,但在之后立即可见(使用git show
)。有人能尝试一下吗?iezvtpos5#
@rasky 在那之后,它也不是为
git show
准备的,尽管对我来说是这样。你在一个非golang/go
的仓库上测试过吗?比如x/image
?des4xlb06#
我认为无论如何都应该恢复使用
codereview
。指南中的其余工作流程也使用了它,我认为对于第一步来说真的没有任何理由避免使用它。如果你添加了git别名(我相信大多数常规贡献者最终都会这样做),git change <name>
的输入速度也比git checkout -b <name>
快。n8ghc7c17#
@dwbuiten: 我已经在
golang/go
上测试过了。所以它对我有效,但对你无效。有其他人能帮忙测试一下吗?这样我们就能了解发生了什么。@ALTree: 我不同意应该回退这个改动。贡献指南并不是为了给有经验的或者经常贡献的人提供全面参考;它只是新手教程。我们越少强迫他们学习的概念,就越容易让他们提交第一个补丁。创建一个用于补丁的分支是大部分(所有)git用户都会知道的标准工作流程的一部分;要求他们使用
git codereview change
就不是了,这会影响到工作副本,以至于我(作者)都无法完全理解为什么这个问题会出现在@dwbuiten身上(参见我不明白为什么这个问题会出现在这里)。我也不想在最初的时候向用户解释git codereview change <branchname>
和git checkout -b <branchname>
相似但又不完全相似。gk7wooem8#
我认为我现在明白了发生了什么:在每个仓库中,钩子作为第一次代码审查命令的副作用被安装。所以如果你运行
change
,你会在提交之前得到钩子的安装。安装了钩子之后,checkout -b
对于描述的流程也能正常工作。这是不幸的,因为看起来无法将mail
作为第一个命令教授给别人。我会考虑这个问题。pxy2qtax9#
@rasky 这解释了很多,比如为什么其他人无法复现。谢谢!
我想总会有像
git codereview init
这样的丑陋路线,但那相当...一般般。