“git push”的默认“refspec”集

Question

在此之前，我认为git fetch 和git push 对$GIT_DIR/config 的影响是相同的，因为两者都是repository engagements 的命令但是当我们为当前存储库添加一个存储库为remote repository 时，Git 会创建git fetch 在config 中的默认refspec 集，例如：

fetch = +refs/heads/*:refs/remotes/remote_repository/*

为什么对配置文件中 git push 的默认 refspec 集不做同样的事情？

我猜差异是由default 命令的目的引起的：

• fetch 的默认用途是用于downloading all objects and refs from another repository
• push 的默认用途是 updating specific remote refs along with associated objects

但我不确定我的猜测。是真的吗？

Answer 1

git push 的工作方式有点不同。

你可以设置push.default参数来控制它。

---

这是 git v2.0 发布说明，它解释了 git 处理推送方式的变化（简单与匹配）。这已在 git v2.0 中进行了更新，以修复默认的 git push 行为。

在 git v2.0 之前，当您执行 git push 时，它会推送您所有更改的分支（所有，而不仅仅是当前分支）。

Git v2.0 发行说明

向后兼容性说明

当git push [$there] 没有说要推送什么时，我们使用了 到目前为止的传统 matching 语义（您的所有分支都已发送 到远程只要已经有同名的分支 在那边）。在 Git 2.0 中，现在默认是 simple 语义， 哪个推动：

• 只有当前分支到同名分支，并且只有 当前分支设置为与该远程集成时 分支，如果您推送到与您获取相同的远程；或

• 只有当前分支到同名分支，如果你 正在推送到您通常不从那里获取的远程。

你可以使用配置变量push.default来改变 这。如果您是一位想要继续使用 matching语义，可以将变量设置为matching，为 例子。阅读文档以了解其他可能性。

Answer 2

简单地说，一个分支可以从一个远程跟踪分支中拉出并推送到另一个。

即使您设置了默认推送策略 (git config push.default)，that would be overridden by a local branch.<name>.push config。

Since git 2.5，您可以轻松区分用于 fetch 和 push 的 refspec（如果分支没有 push refspec，则默认为 fetch ）

例如，如果你在你的 master 分支上，并且想看看你是否领先或落后于你推送到的远程跟踪分支（默认情况下，origin/master，但它可能是任何其他远程分支，如果branch.master.push 在配置中设置）

git for-each-ref --format="%(push:track)" refs/heads

快捷方式<branch>@{push}直接引用配置中设置的值branch.master.push。

例如，查看您尚未推送的提交：

git log @{push}..

---

请注意，在 Git 2.22（2019 年第二季度）之前，“--format”选项中使用的%(push:track) 令牌和“git for-each-ref”和朋友没有显示正确的分支。
此问题已修复。

参见Damien Robert (DamienRobert) 的commit c646d09（2019 年 4 月 16 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit f560a4d，2019 年 5 月 8 日）}

ref-filter：为%(push:track) 使用正确的分支

在ref-filter.c 中，处理原子%(push:track) 时， 前面/后面的值是使用 stat_tracking_info 计算的，它指的是 到上游分支。

通过在 stat_tracking_info 中引入新标志 for_push 来解决此问题 在remote.c 中，它做同样的事情，但对于推送分支。
更新stat_tracking_info 的少数调用者来处理这个标志。这 确保我们以后每次使用这个功能时，小心谨慎 要指定这应该适用于上游还是推送分支。

---

警告：当相同的代码路径开始处理“%(push:<what>)”时，“for-each-ref”和朋友的“%(push)”格式元素的处理被破坏，这已在 Git 2.32（2021 年第二季度）中更正。

见ZheNing Hu (adlternative)commit 1e1c4c5（2021 年 5 月 11 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 36a255a，2021 年 5 月 20 日）}

ref-filter: 修复读取无效的联合成员错误

^{签字人：胡哲宁
[jc：进一步的测试修复]
签字人：Junio C Hamano}

used_atom.u 是一个联合，它有不同的成员，具体取决于“struct used_atom" 的联合部分要记录的辅助数据是什么原子。
任何时候最多只能有一个成员有效。
由于代码检查u.remote_ref 甚至没有确定原子是“push”还是“push:”（这只是u.remote_ref.push 有效的两种情况），但u.remote_ref 共享相同的存储空间工会成员，检查是从一个无效成员那里读取的，这是错误。

这里修改条件，检查原子名称是否等于“push”或以“push:”开头，避免读取无效联合成员的值。