git push:期望的提交者名称/电子邮件 [英] git push: expected committer name/email
问题描述
针对此问题列出的解决方案无效。
我有一个2个遥控器的回购。我一直在bitbucket中工作,但我需要从gitlab中抽取和合并一些更改。所以我执行了这个:
$ git checkout master
$ git pull gitlab master
$ git checkout branchA
$ git merge master#没有冲突
$ git push gitlab branchA#没有问题
$ git push bitbucket branchA#!FAILURE!
现在我收到了一堆错误,指出期望的提交者名称 code>或
并且合并到期望的提交者电子邮件
。对于从 gitlab
拉取的 branchA
。那些在 master
中的提交是由其他人创建的,但是合并到 branchA
是由我创建的。
是否可以解决这个问题?
每个Git都是自己的独立实体,并且可以自己制定规则(或者由Git管理员补充它)。
看起来机器/ URL中的Git你正在调用 gitlab
有简单的规则,允许提交虚假或提交者名称和/或电子邮件地址,你自己的机器上的Git同样宽容。尽管如此,你调用的URL
这些在master中的提交是由其他人创建的,但是合并到
branchA
是由我制作的。
是否有可能解决这个问题?
不是在你的最后,没有。你可以避开它,但是你不能解决它。
基本上,问题是您从Git获得的提交对象位于 gitlab
并存储到您自己的Git存储库中,不符合Git <
<这可能是可能的,但不是你可以做的。如果 ,那么您可以在连接的Bitbucket结尾执行此操作,并且/或者他们(Bitbucket人员)提供了适当的旋钮来设置其控制权限严格性。
或者,您可以在保留这些提交对象的同时,使新增并改进提交非常类似于原始对象的对象,但已经修正了 bitbucket
中的Git正在反对的内容。然后,您可以将您的工作与这些新增和改进的提交合并,然后将结果推送到位于 bitbucket
的Git,他们现在可能会对它们感到满意。这就是我上面所说的回避。你实际上并没有固定任何东西:破坏(在Git的眼中,在 bitbucket
无论如何)提交仍然被破坏。您只是不再使用它们,至少在以 bitbucket
的形式将内容发送到Git中。
要一次复制提交,可以使用 git cherry-pick
。由此产生的提交默认情况下,原作者将作为作者,而您将作为提交者。要复制整体提交,你可以使用 git rebase
(这在各种方面有点棘手)或者 git filter-branch
(它给了你对复制过程的巨大控制,但是在几个方面都非常棘手,因为随着所有的控制,你必须真正知道所有的控制)。在任何情况下,您的新副本都不会与原件相同 - 因为原件无法更改,所以必定会出现这种情况,并且会让所有需要使用原件和新副本(这可能包括你自己)。所以它可能不会成为一种方式,除非你能以某种方式说服每个人切换到新的更正提交。
The solution listed for this question did not work.
I have a repo with 2 remotes. I have been working in bitbucket, but I needed to pull and merge some changes from gitlab. So I executed this:
$ git checkout master
$ git pull gitlab master
$ git checkout branchA
$ git merge master # no conflicts
$ git push gitlab branchA # no issues
$ git push bitbucket branchA # !FAILURE!
I'm now getting a bunch of errors saying expected committer name
or expected committer email
. I'm getting both of these errors for each commit to master
that I pulled from gitlab
and merged into branchA
. Those commits in master
were made by someone else, but the merge into branchA
was made by me.
Is it possible to solve this problem?
Each Git is its own independent entity, and can make up its own rules (or have them made up for it by some Git administrator anyway).
It seems that the Git at the machine / URL that you are calling gitlab
has easy rules that permit commits with bogus or missing committer name and/or email addresses, and your own Git on your machine is equally permissive. The Git over on the URL that you are calling bitbucket
, though, is stricter.
Those commits in master were made by someone else, but the merge into
branchA
was made by me.Is it possible to solve this problem?
Not at your end, no. You can sidestep it, at some cost, but you cannot solve it.
Fundamentally, the issue is that the commit objects you obtained from the Git at gitlab
and have stored into your own Git repository don't meet the requirements imposed by the Git at bitbucket
. Moreover, every Git object is read-only: once made, it can never be changed. The only way those existing Git objects would pass the requirements imposed by the Git at bitbucket
is if those requirements are loosened.
That might be possible, but is not something you can do at your end. You can do it at the Bitbucket end of the connection if you have enough administrator privileges there and/or they (the Bitbucket folks) have provided appropriate knobs to set to control its strictness.
Alternatively, you can, while leaving these commit objects alone, make new and improved commit objects that are very much like the originals, but have corrected whatever it is that the Git at bitbucket
is objecting to. You can then merge your work with these new-and-improved commits, and push the result to the Git at bitbucket
, who will presumably now be happy with them. That's what I call "sidestepping" above. You haven't actually fixed anything: the broken (in the eyes of the Git at bitbucket
anyway) commits are still broken. You're just no longer using them, at least in terms of sending stuff to the Git at bitbucket
.
To copy commits one-at-a-time, you can use git cherry-pick
. The resulting commits will have the original author as author, and you as committer, by default. To copy commits en-masse, you can use git rebase
(which is a little bit tricky in various ways) or git filter-branch
(which gives you enormous control over the copying process, but is a lot tricky in several ways because along with all that control, you must actually know what all the controls do).
In any case, your new copies will not be the same as the originals—that's necessarily the case, since the originals cannot be changed—and will create headaches for everyone who needs to use both the originals and the new copies (this probably includes yourself). So it may not be the way to go, unless you can somehow convince everyone to switch over to the new "corrected" commits.
这篇关于git push:期望的提交者名称/电子邮件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!