如何在 git-svn 中设置上游分支？答案

【问题标题】：How to set upstream branch in git-svn?如何在 git-svn 中设置上游分支？
【发布时间】：2014-04-09 08:50:25
【问题描述】：

在处理普通的 git 存储库时，本地分支通常会跟踪相应的远程上游分支。通过这种方式，我可以很容易地看到我是在上游分支之前还是之后，因此我是否需要推动或拉动以使它们同步。而且我的prompt立马就显示这个状态，很方便。

现在我正在使用git-svn 开发一个 SVN 存储库。我使用--prefix=svn 进行克隆，因此git branch -r 将svn/trunk 列为远程分支，但是（尽管git svn rebase 工作没有问题）它没有配置为我的主分支的上游分支。

我尝试手动设置跟踪信息但失败：

$ git branch -r
  svn/trunk
$ git branch --set-upstream-to=svn/trunk
fatal: Cannot setup tracking information; starting point 'svn/trunk' is not a branch.

有什么方法可以跟踪 svn 上游分支吗？

还有其他简单的方法可以知道我在那个分支的前面还是后面？（查看gitk --all是目前我知道的唯一方法。）

有没有办法让我的 (bash __git_ps1) 提示符显示该信息？

$ git --version
git version 1.9.0.msysgit.0

【问题讨论】：

FWIW，我看到与 1.9.2 相同的行为并且没有手动选择的前缀 IIRC（我有一个遥控器/主干）。

标签： git svn git-svn msysgit git-bash

【解决方案1】：

git-svn 会将配置数据存储在.git/config 中，例如在我的一个仓库中，配置如下：

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[svn-remote "svn"]
    url = http://svn.repo.com/repos/myrepo
    fetch = trunk:refs/remotes/trunk
    branches = branches/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*

在[svn-remote "svn"] 部分，您可以看到所有git-svn 配置。在branches 部分，您可以看到远程svn 存储库上的所有分支。

当我需要关注本地 git 仓库中的 svn 分支时，我通常会执行以下步骤：

我检查config 是否正确配置了所有branches 和tags。
我做了一个git svn fetch，这样 git 将获取所有分支的 repo 中的所有数据
我检查所有branches / tags 都作为git branch -a 的输出出现，例如：
```
master
prod
scenarioParametro
remotes/tags/alpha-1
remotes/trunk
```
我创建了一个本地 git branch 来跟踪远程：
```
git branch alpha-1 remotes/tags/alpha-1 --track
```

这样新创建的alpha-1 分支将跟随remotes/tags/alpha-1，您可以执行rebase 和dcommit 命令。

【讨论】：

不，--track 不适用于我的存储库。它将导致与问题中所示相同的错误消息。（无法设置跟踪信息。）它真的适用于您的存储库吗？哪个版本的 git 和哪个操作系统？
@michas：它对我有用，我在 10 个或更多 repos 上使用这个过程......顺便说一句，linux 和 git 1.7.9.5。在您的回购中执行git svn fetch 之后，您能否发布git branch -a 的结果？
我已经在问题中给出了git branch -r 的输出。 git branch -a 只会添加我的本地 master 分支。
跟踪远程 git-svn 分支不再适用于 Git 版本 1.8.3.2。

【解决方案2】：

这似乎是 git 1.9 中引入的一个错误，因为 --set-upstream-to 之前完全按照您提到的那样工作。
_{并且 strace 显示上游分支 ref 的正确定位和读取，但是它被忽略了出于某种原因。}

我对这个问题的解决方法是手动编辑.git/config：

$ cat >> .git/config << EOF

[branch "master"]
        remote = .
        merge = refs/svn/trunk
        rebase = true
EOF

——应该等同于：

git branch --set-upstream-to=svn/trunk master

&& git config branch.master.rebase true（无论如何你都需要 svn）

——但不是，因为一个错误！ “当然我的refs/svn/trunk是一个分支！”你说，然后直接编辑配置（只需一点点温和的力量）。

您的 svn 主干在 git 中的命名可能不同，具体取决于您克隆 repo 的方式（-s、-T、--prefix 选项为 git svn clone）。只需执行git branch -avv 并找到正确的。例如，一个可能的名称是refs/remotes/git-svn；或refs/svn/trunk 同上；甚至是别的东西。

2015 年 11 月更新

我仍然在git version 2.1.4 上复制此内容。有人麻烦提交错误报告吗？

【讨论】：

默认情况下，.git/config 中没有 master 分支的条目，添加一个没有效果。 svn 上游分支似乎存储在其他地方。
@Zitrax 我不太明白你的评论。是的，一个特殊的.git/svn 子目录确实维护了git-svn 遥控器上的一些数据；顺便说一句，它主要是人类可读的。然而没有，svn 远程分支像往常一样存储在.git/refs...你可以从上面看到--prefix=svn 的主干引用在.git/refs/svn/trunk 中——注意它不是 .git/svn/... 任何东西。这只是一个普通的 git ref。此外，如图所示编辑了.git/config，我确实在git status 中看到了所需的Your branch is up-to-date with 'svn/trunk'。哦，“svn 上游分支”是什么意思？
“svn 上游分支”是指运行 git svn dcommit 时更新的 svn 分支。按照您上面的建议编辑 .git/config 不会改变 dcommit 对我的影响。但是，当我在下面的回答中使用git rebase ... 时，我确实看到了变化。我可能误解了它的工作原理，或者这是一个不同的问题 - 但我的问题似乎只能通过我给出的答案来解决。
@Zitrax 配置上游分支（通过git branch --set-upstream-to 如 OP 所示，或通过等效编辑 .git/config 如上所述）不应该 影响git svn dcommit 的去向（它确实会影响git push 的去向——但在 git-svn 中不使用）。你肯定对它是如何工作的感到困惑。特别是，盲目地变基不会对您有太大帮助。 man git-svn: ...注意以下规则： git svn dcommit 将尝试在git log --grep=^git-svn-id: --first-parent -1 中命名的SVN 提交之上提交 ← git-svn-id 标签确定dcommit 的去向。
对，如果它仅基于提交消息中的git-svn-id:，那么我理解。我想当我改变基础时，我可以在下次遇到问题时验证。但是，由于我已经有了解决问题的方法，所以我没有什么可以解决的了 - 我只是好奇为什么我们有不同的解决方案。

【解决方案3】：

这对使用 git 1.9.5 的我来说仍然是个问题。

而且我没有得到这里提到的任何解决方案，但这有效：

git rebase origin/remote-branch-name

在那之后git svn dcommit -n 表明它确实会提交到那个svn 分支。

更新：我又遇到了同样的问题，这次上面的方法不起作用。我刚收到消息：Current branch master is up to date. 但是使用：

git rebase -i origin/remote-branch-name

无论如何强制rebase，然后上游设置正确。

【讨论】：

【解决方案4】：

由于没有人回答这个问题：

还有其他简单的方法可以知道我是领先还是落后于那个分支？

是的，是的。在这种情况下，您也可以使用 GIT 用于比较 refs 的一般概念。是ref_from..ref_to

例如：

git log master..svn/trunk - 将为您提供来自svn/trunk 的所有在您的master 中缺失的提交。 IE。 即将进行更改。

git log svn/trunk..master - 将为您提供来自master 的所有在svn/trunk 中缺失的提交。 IE。 即将发布的更改。

一般语法的进一步解释：here on SO和官方GIT documentation

【讨论】：