0

我使用以下命令将本地分支更改推送到远程分支（在一些自动化脚本中）：

#while being on main branch
git checkout -B new_local_branch_unix_timestamp

#optionally modify some files

# check if there are modified files
git diff --exit-code

# if there are changes commit and push
git commit -am 'commit message'
git push --set-upstream origin new_local_branch_unix_timestamp

# get latest local commit id 
git rev-parse HEAD

# busy wait until latest remote commit id equal to latest local commit id 
# latest remote commit id is extracted using
git rev-parse origin/new_local_branch_unix_timestamp

忙等待意味着应用git rev-parse origin/new_local_branch_unix_timestamp固定次数，直到本地最后提交 id 等于远程最后提交 id。

运行git rev-parse origin/new_local_branch_unix_timestamp 以获取最新的远程提交 ID 偶尔会返回以下输出和错误。

stdout: origin/new_local_branch
sterr: fatal: ambiguous argument 'origin/new_local_branch_unix_timestamp': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

这是非常罕见和随机的。

我总是通过删除本地存储库、重新克隆远程存储库来缓解它。然后上述步骤成功，直到下一次。

发生这种情况是否有原因，是否有更好的方法来减轻它？

可能有许多早先创建的具有相似名称的远程分支（具有相似的第一个字符，因为 unix 时间戳相似）。

这可能是sterr: fatal: ambiguous argumentgit错误的原因吗？

4

1 回答 1

1

origin/*您的本地 Git 将根据另一个 Git 存储库中存在的分支名称（以及找到的哈希 ID）创建或更新名称origin。如果你设置fetch.prune或true使用git fetch --pruneor git remote update --prune，你的本地 Git 也会根据其他 Git 的分支名称删除名称。 origin/*

更新是“机会主义地”发生的。也就是说，你的 Git 从他们的 Git 中获取一些或全部分支名称和哈希 ID 的列表，在某些操作上：特定的git fetch（或git remote update，这在很大程度上是相同的代码）。如果您的 Git 此时具有或获得了适当的提交，那么您的 Git 就能够在此时创建或更新您的远程跟踪名称，并且会这样做。

在非常旧的 Git 版本（早于 1.8.4）中，即使机会出现并且您必须使用不受限制的 git fetch强制更新发生。

当您的本地 Git 存储库没有创建与origin/*您希望 Git 看到的某个分支名称相对应的远程跟踪名称时，就会出现您看到的错误。在这种情况下，运行git fetch（有或没有--prune）或git remote update应该解决问题。

你有一个相当抽象的评论：

# busy wait until latest remote commit id equal to latest local commit id

不清楚的是您如何实现这种“忙等待”：它是否使用git fetch，如果是，是否使用受限制的git fetch. 如果您使用的是受限制的git fetch并且拥有特别古老的 Git，那么您肯定会看到问题。即使您使用的是不受限制的git fetch并且拥有现代 Git，我也可以在这里设想比赛，具体取决于您如何实现此操作，您没有描述。

于 2021-08-04T15:49:44.883 回答