我同意这里。 特别是因为提交对话框有效地充当了 gui 中的“git status”。

您对这些场景有何期望：

步骤 0：

1. 在主（浏览）表单中单击“提交”按钮，提交对话框打开。
2. 最小化提交对话框并将焦点切换回主窗口。
3. 再次单击“提交”按钮。
   问：应该弹出现有对话框还是创建新的对话框副本？

步骤 1：

1. 在主（浏览）表单中单击“提交”按钮，提交对话框打开。
2. 将焦点切换回主窗口并关闭它。
   问：提交对话框也应该关闭吗？

步骤 2：

1. 在主（浏览）表单中单击“提交”按钮，提交对话框打开。
2. 将焦点切换回主窗口并注意新的提交还不存在。
3. 将焦点切换到提交对话框并提交部分文件（或部分更改的行），创建了新的提交，但提交对话框仍然打开。
4. 返回主窗口。
   问：提交历史图表是否应该已经包含新的提交？

1. 现有对话框
2. 关闭对话框
3. 提交对话框应在提交后关闭，历史应显示新提交

无论如何，这是我的看法。

0：现有对话框

1：关闭对话框

2：图表应该包含新的提交，提交对话框应该根据选择的选项关闭（就像现在一样）

我也想支持这个请求。 例如，我必须关闭提交对话框才能进入复制提交消息的历史记录，这感觉很不自然。

高度赞赏。

还有另一个问题。 当提交对话框打开并且用户将更改工作目录时，GitExtensions 应该做什么？
a) 关闭提交对话框
b) 保持对话框打开并刷新它的内容。
c) 保持对话框打开并使用以前的 repo。
d) 当有打开的对话框时，不允许更改工作目录。
e) 其他想法。

我期望“c”，但是在“提交”按钮上重复单击应该打开新的对话框实例。 每个 repo 一个对话框实例（因此，如果您将工作目录更改回来，将再次使用第一个实例而不是打开第三个实例）。

c) 保持对话框打开并使用以前的 repo。

并提供“更新本地更改”，在左侧的更改文件树中表示（未分级）。 这种情况在当前状态下已经是可能的，并且不受对话模式的影响。 但是，应该清楚的是，不应从 GitExt 进行本地更改。
我认为更改分支或当前提交（即索引） - “硬”是不可接受的； 工作目录应该保持不变 - 在这一点上使用有限，但我看不出有什么理由不应该这样做。

或者，“提交给...（分支|提交）”。

我最近使 ViewPullRequestForm 无模式。 当我单击 FormBrowse 时，它​​会响应，但会停留在 ViewPullRequestForm 后面。 有谁知道激活 FormBrowse 后在 ViewPullRequestForm 前面显示 FormBrowse 的任何设置？

您可以从 ViewPullRequestForm 的调用 Show()/ShowDialog() 中删除父参数。

我试过了，但没有帮助。

我认为当前的无模式表单行为从用户的角度来看并不直观，因为应用程序在关闭主窗口时退出。

我认为我们有几个选择：

• 尝试纠正当前实现中的问题
• 每次运行新的应用程序实例
• 将所有无模式窗口 FormBorderStyle 更改为 FixedToolWindow/SizableToolWindow 以便用户至少可以期待这种行为

我经常被这个绊倒。 我定期进行小提交，因此保持提交窗口左右。

这种情况不断发生：

1）提交一些东西
2）最小化窗口
3) 继续
4）回到Git Extensions主窗口并尝试点击东西
5）当它只是闪烁并发出错误噪音时会感到沮丧
6）意识到在我的屏幕最左边有一个很小的最小化模态窗口

请使其成为非模态或删除最小化的能力。 我投票赞成前一个选项。

您可以暂存和取消暂存，然后关闭提交对话框并带上它
随时备份。

2013 年 7 月 18 日星期四上午 11:14，Drew Noakes [email protected]写道：

我经常被这个绊倒。 我定期进行小额提交，所以保持
关于提交窗口。

这种情况不断发生：

1）提交一些东西
2）最小化窗口
3) 继续
4）回到Git Extensions主窗口并尝试点击东西
5）当它只是闪烁并发出错误噪音时会感到沮丧
6）意识到在最左边有一个很小的最小化模态窗口
我的屏幕

请使其成为非模态或删除最小化的能力。 我投票
对于前一种选择。

—
直接回复此邮件或在 Gi tHub上查看 https://github.com/gitextensions/gitextensions/issues/564#issuecomment -21190625
.

_杰伊·阿斯伯里_
PC 维修和定制程序 30 美元/小时 1 小时分钟
我的自行车博客http://vbjaybiking.blogspot.com

@vbjay ，我知道，这不仅仅是我习惯使用提交窗口的方式:) 我大部分时间都在 Linux 上使用其他按我期望的方式工作的工具。 很高兴作者决定什么是最好的。 只是我的 +1 改变。

模态提交对话框的另一个令人讨厌的地方是，它在获得焦点时会将主窗口向前移动。

例如，如果您将主窗口停靠在左侧，然后打开提交对话框并将其停靠在右侧，然后您打开停靠在左侧的 IDE 并聚焦提交对话框，则主窗口会遮挡 IDE。 您最终不得不稍微调整一下窗户以使其达到您想要的方式。

我最近意识到我基本上只使用提交窗口，我很乐意独立启动它。 我真的很喜欢用鼠标提交补丁的能力（而不是在控制台上以交互方式），但所有其他 git 的东西在命令行上感觉更舒服。

考虑到这一点，我对@vcpp提出的三个问题的回答是：

1. 在存储库的基础上重用提交窗口（我希望为不同的项目打开多个提交窗口）。
2. 让提交窗口保持打开状态
3. 在子窗口中提交会通知主窗口有新的提交，因此会立即更新

@NJAldwin 、 @jbialobr和我自己（三位受访者）之间似乎在除第二点之外的所有内容上达成了一致，并且可以通过这个现有下拉列表中的一个选项来控制：

在 UX Stack Exchange 网站上有一些有趣的讨论：

http://ux.stackexchange.com/questions/39778/benefits-and-drawbacks-of-modal-windows

似乎归结为您是否将提交窗口用于短暂的咒语，或者是否将其保持打开状态。 像 Git Extensions 这样的工具适合各种工作流开发人员。 仅在这个问题上，我觉得它是为与我的工作流程不同的人设计的。 有趣的是，我团队中的其他开发人员也分享了这种观点。

最近，在主窗口下部窗格的选项卡控件中添加了一个控制台。 为什么不能将提交窗口也添加为选项卡？

这对我来说似乎是一个很好的解决方案。

这是一个模型。 标签标题需要更改。 也许第二个“提交”选项卡变成了“更改”。

您仍然可以为喜欢它的用户保留现有的提交窗口。 至少从视觉角度来看，控件可以被重用（减去关于在提交时关闭对话框的选项等）。

这对我来说似乎是一个很好的解决方案。

这确实是个好主意！ 大多数时候，我切换到浏览对话框只是为了打开提交对话框。

我会看到的唯一问题是 ui 减速。 那是很多
功能整合为一种形式。 也许直到更新控件
选项卡处于活动状态。

2017 年 3 月 20 日星期一下午 1:36 Janusz Białobrzewski <
通知@github.com> 写道：

这对我来说似乎是一个很好的解决方案。

这确实是个好主意！ 大多数时候我切换到浏览对话框
仅打开提交对话框。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/gitextensions/gitextensions/issues/564#issuecomment-287837834 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ADdhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
.

懒惰地加载 UI 似乎是合理的（虽然不熟悉代码）。

我认为如果我们想将 FormCommit 集成到主窗体，那么我们应该在整个窗口中移动“控制台”、“提交...”选项卡

@KindDragon似乎在逻辑上是一致的，因为它们都不依赖于图中选定的提交。

缺点是失去了更多的垂直空间，并增加了在 UI 中导航所需的鼠标移动和点击量。 通常 UI 对用户来说更友好/自然，即使它对程序员来说不那么合乎逻辑。

如果您要在顶部引入选项卡，我个人更喜欢它们用于存储库，以便我可以在一个窗口中跟踪多个存储库。 这不是这个问题的重点，但在这样做之前，值得考虑顶级选项卡控件的替代用法。

如果提交表单位于图表下方，一个会更好的工作流程是创建修复提交。 您需要的一切都将在屏幕上显示。 我确信两个最受关注的 UI 元素是图形和提交窗口。 使提交模式很难将这两者结合使用。 将它们放在选项卡中会更容易，但是让它们同时可见是（在我看来）终极目标。

如果您要在顶部引入选项卡，我个人更喜欢它们用于存储库，以便我可以在一个窗口中跟踪多个存储库。

我在考虑底部的标签。

在底部的标签栏、中间的标签和顶部的工具栏/菜单之间移动需要大量的鼠标活动来导航您需要去的地方。 IMO，顶部一根，中间一根，比三根要好。 放置在窗格下方的选项卡在 UI 中并不常见。

可能是窗口左侧的一列选项卡（图表、提交、控制台），与顶部对齐。 那会让一切都紧密相连。

考虑使用停靠框架，以便用户可以配置适合他们的布局。 我认为不可能用单一的布局来取悦所有人。 同样，我喜欢在提交时查看图表。

我实际上不喜欢这个提议......对我来说，这意味着不断调整面板（拆分器）的大小。

也许可以通过 VS 中的停靠窗口来实现更好的用户体验（请参阅 https://github.com/gitextensions/gitextensions/issues/3679）。
但是（总是必须有一个）它不适用于非 Windows 用户....

也许用户可以从一组预定义的停靠或非停靠布局中选择布局的“穷人”停靠解决方案是可能的？ 找到一个支持所有人对接的框架可能很难吗？

我添加了一些相关问题：

4033

4031

#4031 中的建议应该与“无模式提交”相关，类似于 @drewnoakes 的模型
我在某种程度上同意@RussKie ，并相信基本提交应该是无模式的，但可以在弹出窗口中完成“完整”提交

• 提交选项卡当前处于隐藏状态。 应该具有与 HEAD 的提交选项卡类似的信息，除了没有提交哈希并且提交消息是“当前 WIP”（初步添加的内容）。

• 增强：可编辑的提交文本。 即使只能从弹出对话框提交，它也会简化提交消息的编写。

• 增强功能：类似于 Commit 弹出窗口的提交按钮

• Diff 选项卡、文件视图上下文菜单以暂存/取消暂存和重置文件

  • 双击文件应该像在浏览（文件历史）中那样工作还是像在提交中那样暂存/取消暂存？

• 增强功能：单独的选项卡，因此可以同时看到 Commit/Diff

  • 移动提交窗口就足够了吗？

您认为在提交图的底部（如@drewnoakes模型）和停靠/取消停靠键盘快捷键可以与首先打开对话框相同（或可配置）的提交对话框“可停靠”的想法是什么。
因此，假设您使用 ctrl+space 打开完整的对话框，但希望它更小，再次 ctrl+space 并且它已停靠。 如果最后一个对话框状态被停靠，则相反。

@drewnoakes你有工作原型吗？ 我很想今天开始使用这个：D

我在年初开始使用 CommitInfo 选项卡来实现，但它基本上复制了 FormCommit 中的所有代码，因此从维护的角度来看解决方案不会很有趣，所以我放弃了它。

关于将此对话框保留为模态但可以选择停靠/取消停靠的任何想法？

从来没有用过。 它是麻省理工学院许可的。 https://github.com/dockpanelsuite/dockpanelsuite

关闭它以支持#5535。

在我个人看来，最好实现这个，反正有一个变通方法，至少在Windows下，就是在文件资源管理器中打开文件夹，右键选择“GitExt Commit...”，这会打开提交对话框独立于打开的任何其他 Git 扩展窗口。