ここで同意します。 特に、コミットダイアログはGUIの「gitstatus」として効果的に機能するためです。

これらのシナリオに何を期待しますか：

ステップ0：

1. メイン（参照）フォームで[コミット]ボタンをクリックし、コミットダイアログを開きます。
2. コミットダイアログを最小化し、フォーカスをメインウィンドウに戻します。
3. もう一度「コミット」ボタンをクリックしてください。
   Q：既存のダイアログをポップアップする必要がありますか、それとも新しいダイアログのコピーを作成する必要がありますか？

ステップ1：

1. メイン（参照）フォームで[コミット]ボタンをクリックし、コミットダイアログを開きます。
2. フォーカスをメインウィンドウに戻し、閉じます。
   Q：コミットダイアログも閉じる必要がありますか？

ステップ2：

1. メイン（参照）フォームで[コミット]ボタンをクリックし、コミットダイアログを開きます。
2. フォーカスをメインウィンドウに戻し、新しいコミットがまだ存在しないことに注意してください。
3. フォーカスをコミットダイアログに切り替え、ファイルの一部（または変更された行の一部）をコミットします。新しいコミットが作成されましたが、コミットダイアログは開いたままです。
4. メインウィンドウに戻ります。
   Q：コミット履歴グラフにはすでに新しいコミットが含まれている必要がありますか？

1. 既存のダイアログ
2. ダイアログを閉じる
3. コミット後にコミットダイアログが閉じ、履歴に新しいコミットが表示されます

とにかく、これは私の意見です。

0：既存のダイアログ

1：ダイアログを閉じる

2：グラフには新しいコミットが含まれている必要があり、選択したオプションに応じてコミットダイアログを閉じる必要があります（現在のように）

このリクエストもサポートしたいと思います。 たとえば、コミットメッセージをコピーするための履歴を取得するためだけに、コミットダイアログを閉じなければならないのは不自然に感じます。

高く評価。

別の問題もあります。 コミットダイアログが開いていて、ユーザーが作業ディレクトリを変更する場合、GitExtensionsは何をすべきですか？
a）コミットダイアログを閉じる
b）ダイアログを開いたままにして、コンテンツを更新します。
c）ダイアログを開いたままにして、前のリポジトリで作業します。
d）開いているダイアログがある場合は、作業ディレクトリの変更を許可しないでください。
e）その他のアイデア。

「c」を期待していますが、「コミット」ボタンを繰り返しクリックすると、新しいダイアログインスタンスが開くはずです。 リポジトリごとに1つのダイアログインスタンス（したがって、作業ディレクトリを元に戻すと、3番目のインスタンスを開く代わりに最初のインスタンスが再び使用されます）。

c）ダイアログを開いたままにして、前のリポジトリで作業します。

そして、左側の変更のファイルツリー（ステージングされていない）に示されている「ローカル変更の更新」を提供します。 この状況は現在の状態ではすでに可能であり、ダイアログのモダリティの影響を受けません。 ただし、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 [email protected]書き込み：

私はよくこれにつまずきます。 私は定期的に小さなコミットを行うので、
コミットウィンドウについて。

これは起こり続けます：

1）何かをコミットする
2）ウィンドウを最小化する
3）続けて
4）Git Extensionsのメインウィンドウに戻って、クリックしてみてください
5）点滅するだけでエラー音がするのでイライラする
6）左端に小さな最小化されたモーダルウィンドウがあることに気づきます
私の画面の

非モーダルにするか、最小化する機能を削除してください。 投票します
前者のオプションの場合。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/gitextensions/gitextensions/issues/564#issuecomment-21190625で表示してください
。

_ジェイ・アズベリー_
PC修理およびカスタムプログラム$ 30 /時間1時間分
私の自転車ブログhttp://vbjaybiking.blogspot.com

@vbjay 、私は知っています、それは私がコミットウィンドウでの作業に慣れている方法だけではありません:)私はほとんどの時間をLinuxで私が期待する方法で動作する他のツールで過ごします。 著者が何が最善かを決定することを嬉しく思います。 変更のためのちょうど私の+1。

モーダルコミットダイアログのもう1つの厄介な点は、フォーカスされたときにメインウィンドウが前面に表示されることです。

たとえば、メインウィンドウを左にドッキングし、次にコミットダイアログを開いて右にドッキングし、次に左にドッキングしたIDEを開いてコミットダイアログにフォーカスすると、メインウィンドウがIDEを覆い隠します。 あなたはそれをあなたが望むようにするために窓を少し調整しなければならないことになります。

私は最近、基本的にコミットウィンドウのみを使用していることに気付きました。スタンドアロンで起動できれば幸いです。 私は（コンソールでインタラクティブにではなく）マウスでパッチをコミットする機能が本当に好きですが、他のすべてのgitのものはコマンドラインでより快適に感じます。

これを念頭に置いて、 @ vcppによって提起された3つの質問に対する私の答えは次のとおりです。

1. リポジトリベースでコミットウィンドウを再利用します（プロジェクトごとに複数のコミットウィンドウを開きたい）。
2. コミットウィンドウを開いたままにします
3. 子ウィンドウでコミットすると、メインウィンドウに新しいコミットが通知されるため、更新がすぐに行われます。

@ NJAldwin 、 @ jbialobr 、および私（3人の回答者）の間で、2番目のポイントを除くすべてについて合意があるようです。これは、この既存のドロップダウンのオプションで制御できます。

UX StackExchangeサイトでいくつかの興味深い議論があります。

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

コミットウィンドウを短い呪文に使用するか、それとも開いたままにするかによって決まるようです。 Git Extensionsのようなツールは、さまざまなワークフロー開発者に適合します。 この問題だけでも、私のワークフローとは異なるワークフローを持つ人のために設計されたように感じます。 ちなみに、この見解は私のチームの他の開発者によって共有されています。

最近、メインウィンドウの下部ペインのタブコントロールにコンソールが追加されました。 コミットウィンドウをタブとして追加できなかったのはなぜですか？

これは私にとって素晴らしい解決策のようです。

これがモックアップです。 タブのタイトルを変更する必要があります。 たぶん、2番目の「コミット」タブは「変更」になります。

そのように成長したユーザーのために、既存のコミットウィンドウを維持することができます。 少なくとも視覚的な観点からは、コントロールを再利用できます（コミット時にダイアログを閉じることに関するオプションを除く）。

これは私にとって素晴らしい解決策のようです。

それは確かに素晴らしいアイデアです！ ほとんどの場合、[参照]ダイアログに切り替えて[コミット]ダイアログを開くだけです。

私がそれで見る唯一の問題は、UIの速度低下です。 それはたくさんです
機能が1つのフォームにまとめられました。 たぶん、
タブがアクティブです。

2017年3月20日月曜日午後1時36分JanuszBiałobrzewski<
[email protected]>は次のように書いています：

これは私にとって素晴らしい解決策のようです。

それは確かに素晴らしいアイデアです！ ほとんどの場合、[参照]ダイアログに切り替えます
コミットダイアログを開くためだけに。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gitextensions/gitextensions/issues/564#issuecomment-287837834 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ADdhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
。

UIを怠惰にロードすることは合理的であるように思われます（ただし、コードに精通していません）。

FormCommitをメインフォームに統合する場合は、ウィンドウ全体で[Console]、[Commit ...]タブを移動する必要があると思います。

@KindDragonは、どちらもグラフで選択したコミットに依存していないため、論理的に一貫しているように見えます。

欠点は、垂直方向のスペースが減り、UI内を移動するために必要なマウスの移動とクリックの量が増えることです。 多くの場合、UIは、プログラマーにとって論理的ではない場合でも、ユーザーにとってより親しみやすく自然なものです。

上部にタブを導入する場合は、1つのウィンドウで複数のリポジトリを追跡できるように、個人的にはリポジトリ用のタブを使用することをお勧めします。 これはこの問題の焦点では​​ありませんが、そうする前に、トップレベルのタブコントロールの代替使用法を検討する価値があります。

コミットフォームがグラフの下にある場合に適したワークフローの1つは、修正コミットを作成するワークフローです。 必要なものはすべて画面に表示されます。 最も注目されている2つのUI要素は、グラフとコミットウィンドウだと確信しています。 commitをモーダルにすると、これら2つを一緒に使用するのが難しくなります。 それらをタブに入れると簡単になりますが、両方を同時に表示することは（私の考えでは）究極です。

上部にタブを導入する場合は、1つのウィンドウで複数のリポジトリを追跡できるように、個人的にはリポジトリ用のタブを使用することをお勧めします。

一番下のタブについて考えています。

下部のタブバー、中央のタブ、上部のツールバー/メニューの間を移動することは、移動する必要のある場所をナビゲートするための多くのマウスアクティビティです。 上部に1つのバーがあり、中央に1つのバーがある方が、IMOの3つのバーがあるよりも優れています。 ペインの下に配置されるタブは、UIではあまり一般的ではありません。

たぶん、ウィンドウの左側にあるタブの列（Graph、Commit、Console）が、上部に配置されています。 それはすべてを近くに保つでしょう。

ユーザーが自分に合うようにレイアウトを構成できるように、ドッキングフレームワークの使用を検討してください。 1つのレイアウトでみんなを喜ばせることはできないと思います。 繰り返しますが、コミットしている間、グラフを見るのが好きです。

私は実際にその提案が好きではありません...私にとって、それはパネル（スプリッター）のサイズを絶えず変更することを意味します。

おそらく、VSのようにドッキングされたウィンドウを使用すると、より優れたUXを実現できます（https://github.com/gitextensions/gitextensions/issues/3679を参照）。
ただし、（常に1つある必要があります）Windows以外のユーザーには機能しません。

おそらく、ユーザーが事前定義されたドッキングまたはドッキング解除されたレイアウトのセットからレイアウトを選択できる「貧弱な」ドッキングソリューションが可能でしょうか。 すべての人のドッキングをサポートするフレームワークを見つけるのは難しいかもしれませんか？

私はいくつかの関連する問題を追加しました：

4033

4031

@drewnoakesによるモックアップに似た「モードレスコミット」に関連するはずの＃4031の提案
私は@RussKieにある程度同意し、基本的なコミットはモードレスであるべきだと信じていますが、「完全な」コミットはポップアップで実行できます

• 現在、[コミット]タブは非表示になっています。 コミットハッシュがなく、コミットメッセージが「現在のWIP」（事前に追加されたもの）であることを除いて、HEADのコミットタブと同様の情報が必要です。

• 機能強化：編集可能なコミットテキスト。 ポップアップダイアログからのみコミットできる場合でも、コミットメッセージの記述が簡単になります。

• 機能強化：「コミット」ポップアップに似た「コミット」ボタン

• 差分タブ、ファイルをステージング/アンステージングおよびリセットするためのファイルビューコンテキストメニュー

  • ブラウズ（ファイル履歴）のようにファイルをダブルクリックするか、コミットのようにステージング/アンステージングする必要がありますか？

• 機能強化：タブを分離して、コミット/差分を同時に表示できるようにします

  • コミットウィンドウを移動するだけで十分ですか？

コミットグラフの下部にコミットダイアログを「ドッキング可能」（ @drewnoakesモックアップなど）にし、キーボードショートカットをドッキング/ドッキング解除することは、最初にダイアログを開くのと同じ（または構成可能）であるという考えをどう思いますか。
つまり、ctrl + spaceを使用して本格的なダイアログを開きますが、それを小さくしたい場合は、ctrl + spaceをもう一度押してドッキングします。 そして、最後のダイアログ状態がドッキングされていた場合はその逆です。

@drewnoakes実用的なプロトタイプはありますか？ 今日から使い始めたいです：D

今年の初めにCommitInfoタブを使用して実装を開始しましたが、基本的にFormCommitのすべてのコードを複製したため、メンテナンスの観点からソリューションが面白くなく、削除しました。

このダイアログをモーダルのままにして、ドッキング/ドッキング解除するオプションを使用することについて何か考えはありますか？

使用したことはありません。 MITライセンスです。 https://github.com/dockpanelsuite/dockpanelsuite

＃5535を支持してこれを閉じます。

私の個人的な意見では、とにかく、これを実装する方が良いでしょう。少なくともWindowsでは、ファイルエクスプローラーでフォルダーを開き、右クリックして[GitExt Commit ...]を選択するという回避策があります。これにより開きます。開いた他のGit拡張機能ウィンドウとは独立してコミットダイアログ。