这个场景让我非常讨厌。
杰克在一家软件公司工作，杰克是Working Programmer，他喜欢编码和经常提交。作为杰克经理的保罗告诉他，我们将开始使用新的代码审查工具phabricator。 Jack遵守规定，Jack创建了一个本地分支并开始工作。他经常向当地分支机构添加功能和提交。现在，他在一天结束时发送了一个phabricator请求。
arc diff development
杰克团队成员John回顾他的代码并接受他的更改。 现在，Jack打开终端并移动到他的存储库目录。 Jack键入以下命令以关闭修订并将其代码与开发分支合并。
arc land --onto development
他看到以下消息
Landing current branch 'feature-awesome-features'.
Switched to branch development. Updating branch...
The following commit(s) will be landed:
b2ff76e Added the foo to bar
33f33ba Added a really important check which can destroy the project or save it
31a4c9a Added that new awesome feature
8cae3bf rewrote that awful code john wrote
bc54afb bug fixes
Switched to branch feature-awesome-features. Identifying and merging...
Landing revision 'D1067: Added the awesome feature'...
Rebasing feature-awesome-features onto development
Already up-to-date.
Pushing change...
现在杰克打开Github看他的代码，他美丽的提交。但是他所看到的只是纯粹的恐怖，他的所有提交都被一个提交所取代，基本上就是这样的事情
Summary: Added the awesome feature
Test Plan: do foo bar testing
Reviewers: John
Reviewed By: John
CC: Paul
Differential Revision: http://phabricator.foobar.com/D1067
现在杰克很伤心，因为他想看到他所有的承诺，杰克认为这个承诺使他看起来像The Hoarder他不是。他想解决这个问题，所以他去问一个关于stackoverflow的问题。
That how may he prevent phabricator from eating his commit history.
答案 0 :(得分：20)
asherkin的回答解释了这种行为的基本原理，以及为什么这是默认行为。
如果您没有发现该参数令人信服，则可以使用--merge标记arc land来执行--no-ff合并，而不是--squash合并。这些合并不会破坏本地提交。
如果您在history.immutable中将.arcconfig设置为true，则arc land默认会--no-ff合并。
如果您不喜欢git的行为，也可以使用原始arc land命令;它仅为方便起见而提供。
在您的示例中，我们建议创建五个单独的评论 - 有多个不同的想法正在实施，它们没有关联，似乎很容易分开。见Writing Reviewable Code。将错误修正，样式更改和新功能组合到一个更改中是囤积。
答案 1 :(得分：9)
您应该直接使用本地git流，例如git merge和git push。来自phabricator arc documentation：
接受更改后，通常会推送并关闭 修订。 arc有几个工作流程可以帮助解决这个问题：
* squashing or merging changes from a feature branch into a master branch * formatting a good commit message with all the information from Differential * and automatically closing the revision.您不需要使用任何这些工作流程：您只需运行git即可 push，hg push或svn commit，然后手动关闭修订版 网络。
arc故意压制你的提交。
答案 2 :(得分：3)
有some documentation解释了为什么这是arc land的默认设置。
一个策略，其中一个想法是一个提交没有任何其他策略的真正优势，直到您的存储库达到它变得至关重要的速度。特别是：
- 基本上针对主/远程存储库的所有操作都是关于想法，而不是提交。当一个想法是多次提交时，你所做的一切都更复杂，因为你需要弄清楚哪些提交代表一个想法（“foo小部件被破坏，我需要还原什么？”）或者什么想法最终由提交代表（“提交af3291029毫无意义，这个改变试图实现的目标是什么？”）。
- 大大简化了发布工程。当每个想法对应一次提交时，发布工程师可以轻松地选择或删除想法。当一个想法是多次提交时，更容易意外地选择或删除一半的想法，并最终处于几乎保证是错误的状态。
- 大大简化了自动化测试。如果每个想法都是一次提交，则可以针对每次提交运行自动化测试，并且测试失败表明存在严重问题。如果每个想法都是多次提交，那么大多数提交都代表了已知的代码库损坏状态（例如，检查点的语法错误已在下一个检查点中修复，或者具有半实现的想法）。
- 大大简化了解变化。您可以平分到一个中断并轻松识别整个想法，而无需在日志中向前和向后捕获以识别该想法的范围。而且你可以对你需要恢复以消除整个想法的信心充满信心。
- 检查点提交（其中一些保证已知存储库的已损坏版本）持久存在于远程中没有明确的价值。考虑一个理论VCS，它会自动为每次击键创建一个检查点提交。这个VCS显然是无法使用的。但是许多检查点提交并没有太大的不同，并且在概念上代表了在写入更大想法的击键序列中的一些相对任意的点。摆脱它们或创建一个抽象层（合并提交），当你试图根据想法（几乎总是）理解存储库时，你可以忽略它们。
所有这些都只是大规模的问题。 Facebook每天推送数十个想法，每周推送数千个想法，并且如果没有选择存储库策略（其中一个想法是一次提交），就无法做到这一点（至少，不是没有更多人或更多错误）。
对于git，建议的解决方案是将功能分支推送到上游，然后合并而不是重新绑定到主服务器 - 如果您同意上述要点但仍希望您的检查点在上游提交。
如果这只是在审核过程中（因为您的问题措辞有问题 - 但听起来您还没有进行代码审核或只是审核后推送代码审核），请注意差异已经显示所有本地提交使用原始提交消息供审阅者查看。
arc land旨在仅用于推送到存储库的“最终”分支（即生产或代表待发布的更改的某个分支）。如果您正在进行推后提交审核（即从开发到主服务的合并），您可以绕过arc land（在许多情况下通常会接受您需要）和git push您的直接改变。
答案 3 :(得分：3)
history.immutable：配置arc以使用永远不会在工作副本中重写历史记录的工作流。默认情况下，arc将在Git中的某些工作流上执行一些未发布的历史记录（修改提交消息，压缩合并）的重写。下面将详细介绍这些区别。
所以只需在.arcconfig
"history.immutable": true
答案 4 :(得分：0)
- 合并不起作用，因为它创建了合并提交。 我修补了我的--rebase会做正确的事，但我不确定弧人是否愿意这样做。
答案 5 :(得分：0)
这是我的工作。它不会阻止提交历史记录，但可以让您将后续功能重新建立到丢失的分支上。
$ arc land --revision <feature1>
$ git branch -u master <feature2>
$ arc cascade
弧级联将为所有从Feature1分支的要素分支重新设置
答案 6 :(得分：0)
在对奥术师的最新更新中进行了一些更改之后，该问题的现代答案
为了防止壁球，您必须使用新的const puppeteer = require('puppeteer');
const iPhone = puppeteer.devices['iPhone 6'];
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.emulate(iPhone);
await page.goto('https://instagram.com', { waitUntil: 'networkidle0', timeout: 0 }); // wait until page load
// do stuff
await browser.close();
})();
语法
strategy
arc land Dxyz --strategy merge或--merge的旧语法已被--squash取代
（请参见https://secure.phabricator.com/T13547中的一些背景信息）