Ich stimme hier zu. Zumal der Commit-Dialog praktisch als "Git-Status" in der GUI fungiert.

Was erwarten Sie für diese Szenarien:

Schritte 0:

1. Klicken Sie im Hauptformular (Durchsuchen) auf die Schaltfläche "Commit", der Commit-Dialog wird geöffnet.
2. Commit-Dialog minimieren und Fokus zurück zum Hauptfenster schalten.
3. Klicken Sie erneut auf die Schaltfläche "Commit".
   F: Sollte ein vorhandener Dialog erscheinen oder eine neue Dialogkopie erstellt werden?

Schritte 1:

1. Klicken Sie im Hauptformular (Durchsuchen) auf die Schaltfläche "Commit", der Commit-Dialog wird geöffnet.
2. Schalten Sie den Fokus zurück zum Hauptfenster und schließen Sie es.
   F: Soll der Commit-Dialog auch geschlossen werden?

Schritte 2:

1. Klicken Sie im Hauptformular (Durchsuchen) auf die Schaltfläche "Commit", der Commit-Dialog wird geöffnet.
2. Schalten Sie den Fokus zurück zum Hauptfenster und beachten Sie, dass das neue Commit noch nicht existiert.
3. Wechseln Sie in den Commit-Dialog und übergeben Sie einen Teil der Dateien (oder einen Teil der geänderten Zeilen). Es wurde ein neuer Commit erstellt, aber der Commit-Dialog ist noch geöffnet.
4. Zurück zum Hauptfenster.
   F: Sollte das Commit-Verlaufsdiagramm bereits das neue Commit enthalten?

1. Bestehender Dialog
2. Dialog schließen
3. Der Commit-Dialog sollte nach dem Commit geschlossen werden und der Verlauf sollte einen neuen Commit anzeigen

Das ist jedenfalls meine Meinung.

0: Bestehender Dialog

1: Dialog schließen

2: Graph sollte neuen Commit enthalten, Commit-Dialog sollte je nach gewählter Option geschlossen werden (wie er jetzt ist)

Auch diesen Wunsch möchte ich unterstützen. Es fühlt sich unnatürlich an, dass ich den Commit-Dialog schließen muss, nur um zum Beispiel zum Kopieren einer Commit-Nachricht zum Verlauf zu gelangen.

Hoch geschätzt.

Es gibt noch ein weiteres Problem. Was sollten GitExtensions tun, wenn der Commit-Dialog geöffnet ist und der Benutzer das Arbeitsverzeichnis ändert?
a) Commit-Dialog schließen
b) Dialog geöffnet lassen und Inhalt aktualisieren.
c) Dialog geöffnet lassen und mit vorherigem Repo arbeiten.
d) Änderung des Arbeitsverzeichnisses nicht zulassen, wenn Dialoge geöffnet sind.
e) Andere Idee.

Ich erwarte „c“, aber auf die Schaltfläche „Commit“ klicken Sie erneut, um eine neue Dialoginstanz zu öffnen. Eine Dialoginstanz pro Repo (wenn Sie also das Arbeitsverzeichnis zurückwechseln, wird die erste Instanz erneut verwendet, anstatt die dritte Instanz zu öffnen).

c) Dialog geöffnet lassen und mit vorherigem Repo arbeiten.

Und stellen Sie ein "Lokale Änderungen aktualisieren" bereit, das im Dateibaum der Änderungen auf der linken Seite (nicht bereitgestellt) dargestellt ist. Diese Situation ist im aktuellen Zustand bereits möglich und wird durch die Modalität des Dialogs nicht beeinflusst. Es sollte jedoch klar sein, dass lokale Änderungen nicht von GitExt aus vorgenommen werden sollen.
Ich denke, das Ändern des Zweigs oder des aktuellen Commit (dh des Index) - "hart" - wäre nicht akzeptabel; das Arbeitsverzeichnis sollte unberührt bleiben - hat an dieser Stelle nur begrenzten Nutzen, aber ich sehe keinen Grund, warum dies nicht möglich sein sollte.

Alternativ "Commit to ... (branch|commit)".

Ich habe kürzlich ViewPullRequestForm moduslos gemacht. Wenn ich auf FormBrowse klicke, antwortet es, bleibt aber hinter ViewPullRequestForm. Kennt jemand eine Einstellung, um FormBrowse vor ViewPullRequestForm anzuzeigen, nachdem FormBrowse aktiviert wurde?

Sie können den übergeordneten Parameter aus dem Aufruf Show()/ShowDialog() für ViewPullRequestForm entfernen.

Ich habe es versucht, aber es hilft nicht.

Ich denke, dass das aktuelle moduslose Formularverhalten aus Benutzersicht nicht intuitiv ist, da die Anwendung beim Schließen des Hauptfensters beendet wird.

Ich denke, wir haben mehrere Möglichkeiten:

• Versuchen Sie, das Problem in der aktuellen Implementierung zu beheben
• Führen Sie jedes Mal eine neue Anwendungsinstanz aus
• Ändern Sie FormBorderStyle aller nicht modalen Fenster in FixedToolWindow/SizableToolWindow, damit Benutzer dieses Verhalten zumindest erwarten können

Darüber stolpere ich oft. Ich mache regelmäßig kleine Commits und halte so das Commit-Fenster ungefähr aufrecht.

Das passiert immer wieder:

1) Verpflichte etwas
2) Fenster minimieren
3) Weitermachen
4) Kehren Sie zum Hauptfenster von Git Extensions zurück und versuchen Sie, auf Dinge zu klicken
5) Werden Sie frustriert, wenn es nur blinkt und ein Fehlergeräusch macht
6) Stellen Sie fest, dass es ein winziges minimiertes modales Fenster ganz unten ganz links auf meinem Bildschirm gibt

Bitte machen Sie es entweder nicht-modal oder entfernen Sie die Möglichkeit zum Minimieren. Ich stimme für die erstere Option.

Sie können Staging und Unstage durchführen und dann den Commit-Dialog schließen und bringen
jederzeit sichern.

Am Donnerstag, den 18. Juli 2013 um 11:14 Uhr schrieb Drew Noakes [email protected] :

Darüber stolpere ich oft. Ich mache regelmäßig kleine Commits und halte mich daran
das Commit-Fenster über.

Das passiert immer wieder:

1) Verpflichte etwas
2) Fenster minimieren
3) Weitermachen
4) Kehren Sie zum Hauptfenster von Git Extensions zurück und versuchen Sie, auf Dinge zu klicken
5) Werden Sie frustriert, wenn es nur blinkt und ein Fehlergeräusch macht
6) Stellen Sie fest, dass sich ganz links ein winziges minimiertes modales Fenster befindet
meines Bildschirms

Bitte machen Sie es entweder nicht-modal oder entfernen Sie die Möglichkeit zum Minimieren. ich wähle
für die frühere Option.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHubhttps://github.com/gitextensions/gitextensions/issues/564#issuecomment -21190625 an
.

_Jay Asbury_
PC-Reparatur und benutzerdefinierte Programme 30 $/Std. 1 Std. min
Mein Fahrrad-Blog http://vbjaybiking.blogspot.com

@vbjay , ich weiß, so bin ich es nicht nur gewohnt, mit Commit-Fenstern zu arbeiten :) Ich verbringe die meiste Zeit unter Linux mit anderen Tools, die so funktionieren, wie ich es erwarte. Glücklich für die Autoren zu entscheiden, was das Beste ist. Zur Abwechslung nur meine +1.

Ein weiteres Ärgernis des modalen Commit-Dialogs ist, dass er das Hauptfenster mit nach vorne bringt, wenn er fokussiert ist.

Wenn Sie beispielsweise das Hauptfenster links andocken, dann den Commit-Dialog öffnen und rechts andocken, dann eine links angedockt IDE öffnen und den Commit-Dialog fokussieren, verdeckt das Hauptfenster die IDE. Sie müssen am Ende ein wenig mit den Fenstern jonglieren, um es so zu bekommen, wie Sie es möchten.

Ich habe kürzlich festgestellt, dass ich im Grunde nur das Commit-Fenster verwende und es gerne eigenständig starten würde. Ich mag die Möglichkeit, Patches mit der Maus auszuführen (anstatt interaktiv auf der Konsole), aber alle anderen Git-Sachen fühlen sich auf der Befehlszeile angenehmer an.

Vor diesem Hintergrund lautet meine Antwort auf die drei Fragen von @vcpp :

1. Verwenden Sie das Commit-Fenster auf Repository-Basis wieder (ich möchte mehrere Commit-Fenster für verschiedene Projekte geöffnet haben).
2. Lassen Sie das Commit-Fenster geöffnet
3. Das Festschreiben im untergeordneten Fenster benachrichtigt das Hauptfenster über das neue Festschreiben, sodass die Aktualisierung sofort erfolgt

Es scheint, dass zwischen @NJAldwin , @jbialobr und mir (den drei Befragten) in allem außer dem zweiten Punkt Einigkeit besteht, und das könnte durch eine Option in diesem vorhandenen Dropdown-Menü gesteuert werden:

Auf der UX Stack Exchange-Site gibt es einige interessante Diskussionen:

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

Es scheint darauf anzukommen, ob Sie das Commit-Fenster für einen kurzen Zeitraum verwenden oder ob Sie es offen lassen. Ein Tool wie Git Extensions passt in die vielfältigen Workflows der Entwickler. Allein bei diesem Problem habe ich das Gefühl, dass es für jemanden mit einem anderen Arbeitsablauf als meinem entwickelt wurde. Anekdotisch wird diese Ansicht von den anderen Entwicklern in meinem Team geteilt.

Kürzlich wurde der Registerkartensteuerung im unteren Bereich des Hauptfensters eine Konsole hinzugefügt. Warum konnte das Commit-Fenster dort nicht auch als Tab hinzugefügt werden?

Das scheint mir eine tolle Lösung zu sein.

Hier ist ein Modell. Die Registerkartentitel müssten geändert werden. Vielleicht wird die zweite Registerkarte "Übernehmen" zu "Änderungen".

Sie könnten das bestehende Commit-Fenster für Benutzer beibehalten, denen dies ans Herz gewachsen ist. Zumindest aus visueller Sicht könnte das Steuerelement wiederverwendet werden (abzüglich der Optionen zum Schließen des Dialogs beim Commit usw.).

Das scheint mir eine tolle Lösung zu sein.

Es ist in der Tat eine großartige Idee! Meistens wechsle ich nur zum Browse-Dialog, um den Commit-Dialog zu öffnen.

Das einzige Problem, das ich damit sehen würde, ist die Verlangsamung der Benutzeroberfläche. Das ist eine Menge
Funktionalität in eine Form gerollt. Aktualisieren Sie die Steuerung möglicherweise nicht bis zum
Registerkarte ist aktiv.

Am Mo, 20. März 2017 um 13:36 Uhr Janusz Białobrzewski <
[email protected]> schrieb:

Das scheint mir eine tolle Lösung zu sein.

Es ist in der Tat eine großartige Idee! Meistens wechsle ich in den Durchsuchen-Dialog
nur um den Commit-Dialog zu öffnen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/gitextensions/gitextensions/issues/564#issuecomment-287837834 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ADDhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
.

Das träge Laden der Benutzeroberfläche scheint vernünftig (jedoch nicht mit dem Code vertraut).

Ich denke, wenn wir FormCommit in das Hauptformular integrieren möchten, sollten wir die Registerkarten "Konsole", "Commit ..." auf das gesamte Fenster verschieben

@KindDragon , das logisch konsistent erscheint, da keines davon von dem ausgewählten Commit im Diagramm abhängig ist.

Nachteile sind der Verlust von mehr vertikalem Platz und die Erhöhung der Anzahl der Mausbewegungen und -klicks, die zum Navigieren in der Benutzeroberfläche erforderlich sind. Oft ist eine Benutzeroberfläche für den Benutzer freundlicher/natürlicher, auch wenn sie für den Programmierer weniger logisch ist.

Wenn Sie oben Registerkarten einführen würden, würde ich es persönlich vorziehen, wenn sie für Repositories wären, damit ich mehrere Repos in einem Fenster verfolgen könnte. Das ist nicht der Schwerpunkt dieser Ausgabe, aber es lohnt sich, vorher alternative Verwendungsmöglichkeiten für ein Registerkartensteuerelement der obersten Ebene in Betracht zu ziehen.

Ein Arbeitsablauf, der schöner wäre, wenn das Commit-Formular unter dem Diagramm wäre, ist das Erstellen von Fixup-Commits. Alles, was Sie brauchen, wäre auf dem Bildschirm sichtbar. Ich bin mir sicher, dass die beiden am häufigsten betrachteten UI-Elemente das Diagramm und das Commit-Fenster sind. Commit modal zu machen, macht es schwierig, diese beiden zusammen zu verwenden. Sie in Tabs zu platzieren, macht es einfacher, aber sie beide gleichzeitig sichtbar zu haben, ist (meiner Meinung nach) das Ultimative.

Wenn Sie oben Registerkarten einführen würden, würde ich es persönlich vorziehen, wenn sie für Repositories wären, damit ich mehrere Repos in einem Fenster verfolgen könnte.

Ich denke an Registerkarten unten.

Das Bewegen zwischen der Registerkartenleiste unten, den Registerkarten in der Mitte und der Symbolleiste / dem Menü oben ist eine Menge Mausaktivität, um dorthin zu navigieren, wo Sie hin müssen. Einen Balken oben und einen Balken in der Mitte zu haben, ist meiner Meinung nach besser als drei Balken. Registerkarten, die unter ihren Fenstern platziert sind, sind in Benutzeroberflächen nicht so üblich.

Vielleicht eine Spalte mit Registerkarten (Graph, Commit, Console) auf der linken Seite des Fensters, die nach oben ausgerichtet ist. Das würde alles dicht beieinander halten.

Erwägen Sie die Verwendung eines Docking-Frameworks, damit Benutzer das Layout nach ihren Wünschen konfigurieren können. Ich glaube nicht, dass es möglich ist, allen mit einem einzigen Layout zu gefallen. Auch hier mag ich es, die Grafik zu sehen, während ich mich verpflichte.

Ich mag den Vorschlag eigentlich nicht ... Für mich würde es bedeuten, die Größe der Panels (der Splitter) ständig zu ändern.

Vielleicht könnte mit angedockten Fenstern wie im VS (siehe https://github.com/gitextensions/gitextensions/issues/3679) eine bessere UX erreicht werden.
Aber (es muss immer eins geben) es funktioniert nicht für Nicht-Windows-Benutzer ....

Vielleicht wäre eine Docking-Lösung für "arme Männer" möglich, bei der der Benutzer ein Layout aus einem vordefinierten Satz angedockter oder nicht angedockter Layouts auswählen könnte? Es könnte schwierig sein, ein Framework zu finden, das Docking für alle unterstützt?

Ich habe einige verwandte Probleme hinzugefügt:

4033

4031

Vorschläge in #4031, die sich auf das "Modeless Commit" beziehen sollten, ähnlich dem Mockup von @drewnoakes
Ich stimme @RussKie bis zu einem gewissen Grad zu und glaube, dass das grundlegende Commit moduslos sein sollte, aber ein "vollständiges" Commit könnte im Popup erfolgen

• Die Registerkarte Commit ist derzeit ausgeblendet. Sollte ähnliche Informationen wie der Commit-Tab für HEAD haben, außer dass es keinen Commit-Hash gibt und diese Commit-Nachricht „aktueller WIP“ ist (was vorläufig hinzugefügt wurde).

• Verbesserung: Bearbeitbarer Commit-Text. Auch wenn es nur möglich ist, aus dem Popup-Dialog zu übernehmen, wird das Schreiben der Commit-Nachricht vereinfacht.

• Verbesserung: Commit-Schaltflächen ähnlich dem Commit-Popup

• Diff-Registerkarte, Dateiansicht-Kontextmenü zum Staging/Unstage und Zurücksetzen von Dateien

  • Sollte ein Doppelklick auf eine Datei wie beim Durchsuchen (Dateiversionsverlauf) funktionieren oder wie beim Commit bereitstellen/aufheben?

• Verbesserung: Separate Registerkarte, damit Commit/Diff gleichzeitig angezeigt werden kann

  • Genug mit dem Verschieben des Commit-Fensters?

Was halten Sie von einer Idee, den Commit-Dialog "andockbar" am unteren Rand des Commit-Diagramms zu haben (wie @drewnoakes Mockup) und die Tastenkombination zum Andocken / Abdocken könnte das gleiche (oder konfigurierbare) sein wie das Öffnen des Dialogs an erster Stelle.
Angenommen, Sie öffnen den vollständigen Dialog mit Strg + Leertaste, möchten ihn aber kleiner machen, erneut Strg + Leertaste, und er ist angedockt. Und umgekehrt, wenn der letzte Dialogzustand angedockt war.

@drewnoakes hast du einen funktionierenden Prototyp? Ich würde gerne HEUTE damit anfangen :D

Ich habe Anfang des Jahres mit der Implementierung unter Verwendung des CommitInfo-Tabs begonnen, aber es hat im Grunde den gesamten Code in FormCommit dupliziert, sodass die Lösung aus Wartungssicht keinen Spaß machen würde, und ich habe es fallen gelassen.

Irgendwelche Gedanken, diesen Dialog als Modal zu belassen, aber mit der Option, ihn anzudocken/abzudocken?

Nie benutzt. Es ist MIT-lizenziert. https://github.com/dockpanelsuite/dockpanelsuite

Schließe dies zugunsten von #5535.

Meiner persönlichen Meinung nach wäre es besser gewesen, dies zu implementieren, jedenfalls gibt es einen Workaround, zumindest unter Windows, nämlich den Ordner im Datei-Explorer öffnen, mit der rechten Maustaste klicken und "GitExt Commit ..." auswählen, dieser wird geöffnet den Commit-Dialog unabhängig von jedem anderen geöffneten Git-Erweiterungsfenster.