I agree here. Especially since the commit dialog effectively functions as the "git status" in the gui.

What do you expect for these scenarios:

Steps 0:

1. In main (Browse) form click "Commit" button, commit dialog opened.
2. Minimize commit dialog and switch focus back to main window.
3. Click "Commit" button again.
   Q: should existing dialog pop up or new dialog copy should be created?

Steps 1:

1. In main (Browse) form click "Commit" button, commit dialog opened.
2. Switch focus back to main window and close it.
   Q: should the commit dialog be closed too?

Steps 2:

1. In main (Browse) form click "Commit" button, commit dialog opened.
2. Switch focus back to main window and note that the new commit doesn't exist yet.
3. Switch focus to commit dialog and commit part of files (or part of changed lines), new commit was created, but commit dialog is still open.
4. Return to main window.
   Q: Should commits history graph already contain the new commit?

1. Existing dialog
2. Close dialog
3. Commit dialog should close after committing & history should show new commit

This is my opinion, anyway.

0: Existing dialog

1: Close dialog

2: graph should contain new commit, commit dialog should be closed dependent on chosen option (as it is now)

I would also like to support this request. It feels unnatural that I have to close the commit dialog just to get to the history for copying a commit message for example.

Highly appreciated.

There is also another problem. What GitExtensions should do when Commit dialog is open and user will change working dir?
a) Close commit dialog
b) Keep dialog open and refresh it content.
c) Keep dialog open and work with previous repo.
d) Do not allow change working dir, when there are open dialogs.
e) Other idea.

I expect “c”, but on “Commit” button repeat click new dialog instance should be opened. One dialog instance per repo (so if you change working dir back, first instance will be used again instead of opening third instance).

c) Keep dialog open and work with previous repo.

And provide an "update local changes", represented in the file tree of changes on the left (unstaged). This situation is already possible in the current state and is not affected by the modality of the dialog. However, it should be clear that local changes shall not be made from GitExt.
I think changing the branch or current commit (i.e. the index) - "hard" would not be acceptable; the working dir ought to remain untouched - has limited use at this point but I don't see any reason why this shouldn't be possible.

Alternatively, "Commit to ... (branch|commit)".

I made recently ViewPullRequestForm modeless. When I click on FormBrowse it respones, but stays behind ViewPullRequestForm. Does anyone know any setting to show FormBrowse in front of ViewPullRequestForm after FormBrowse is activated?

You can remove parent parameter from call Show()/ShowDialog() for ViewPullRequestForm.

I tried but it doesn't help.

I think current modeless form behavior not intuitive from user point of view because application exits when closing main window.

I think we have several options:

• Try to correct the problem in the current implementation
• Each time run new application instance
• Change all modeless windows FormBorderStyle to FixedToolWindow/SizableToolWindow so users can at least expect this behavior

I often get tripped up on this. I make regular small commits and so keep the commit window about.

This keeps happening:

1) Commit something
2) Minimise window
3) Carry on
4) Come back to Git Extensions main window and try to click stuff
5) Get frustrated when it just flashes and makes an error noise
6) Realise there's a tiny minimised modal window way down in the far left of my screen

Please either make it non-modal or remove the ability to minimise. I vote for the former option.

You can stage and unstage and then close the commit dialog and bring it
back up anytime.

On Thu, Jul 18, 2013 at 11:14 AM, Drew Noakes [email protected]:

I often get tripped up on this. I make regular small commits and so keep
the commit window about.

This keeps happening:

1) Commit something
2) Minimise window
3) Carry on
4) Come back to Git Extensions main window and try to click stuff
5) Get frustrated when it just flashes and makes an error noise
6) Realise there's a tiny minimised modal window way down in the far left
of my screen

Please either make it non-modal or remove the ability to minimise. I vote
for the former option.

—
Reply to this email directly or view it on GitHubhttps://github.com/gitextensions/gitextensions/issues/564#issuecomment-21190625
.

_Jay Asbury_
PC Repair and custom programs $30/hr 1hr min
My Biking Blog http://vbjaybiking.blogspot.com

@vbjay, I know, that's not just how I'm used to working with commit windows :) I spend most of my time in Linux with other tools that work in the way I expect. Happy for the authors to decide what's best. Just my +1 for a change.

Another nuisance of the modal commit dialog is that it brings the main window forward with it when focused.

For example, if you dock the main window left, then open the commit dialog and dock it right, then you open an IDE docked left and focus the commit dialog, the main window obscured the IDE. You end up having to juggle the windows a bit to get it the way you want.

I realised recently that I basically only use the commit window, and I'd be happy to launch it standalone. I really like the ability to commit patches with the mouse (rather than interactively on the console), but all other git stuff feels more comfortable at the command line.

With this in mind, my answers to the three questions posed by @vcpp are:

1. Reuse the commit window on a repository basis (I would like to have multiple commit windows open for different projects).
2. Leave the commit window open
3. Committing in the child window notifies main window of new commit, so update occurs immediately

It seems that there is agreement between @NJAldwin, @jbialobr and myself (the three respondents) on everything except the second point, and that could be controlled by an option in this existing drop-down:

There's some interesting discussion at the UX Stack Exchange site:

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

It seems to come down to whether you use the commit window for a short spell, or whether you leave it open. A tool like Git Extensions fits into the varied workflows developers. On this issue alone I feel like it was designed for someone with a workflow different to mine. Anecdotally, this view is shared by the other developers on my team.

Recently, a console was added to the tab control in the lower pane of the main window. Why couldn't the commit window be added as a tab there too?

This seems like a great solution to me.

Here's a mockup. The tab titles would need to change. Maybe the second "Commit" tab becomes "Changes".

You could still keep the existing commit window for users who have grown to like that. At least from a visual perspective, the control could be reused (minus the options about closing the dialog on commit, etc).

This seems like a great solution to me.

It is indeed a great idea! Most of the time I switch to the Browse dialog only to open the Commit dialog.

The only problem I would see with it is ui slowdown. That is a lot of
functionality rolled into one form. Maybe not update the control till the
tab is active.

On Mon, Mar 20, 2017 at 1:36 PM Janusz Białobrzewski <
[email protected]> wrote:

This seems like a great solution to me.

It is indeed a great idea! Most of the time I switch to the Browse dialog
only to open the Commit dialog.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitextensions/gitextensions/issues/564#issuecomment-287837834,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADdhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
.

Loading the UI lazily seems reasonable (not familiar with the code though).

I think if we want to integrate FormCommit to main form, then we should move "Console", "Commit..." tabs on the full window

@KindDragon that seems logically consistent as neither of those are dependent upon the selected commit in the graph.

Downsides are losing more vertical space, and increasing the amount of mouse moving and clicking required to navigate around the UI. Often a UI is more friendly/natural to the user even when it's less logical to the programmer.

If you were going to introduce tabs at the top, I'd personally prefer if they were for repositories so that I could track multiple repos in one window. That's not the focus of this issue, but it is worth considering alternative usages for a top-level tab control before doing so.

One workflow that would be nicer if the commit form was beneath the graph is that of creating fixup commits. Everything you'd need would be visible on screen. I'm sure the two most looked-at UI elements are the graph and the commit window. Making commit modal makes it hard to use these two together. Putting them in tabs makes it easier, but having them both visible at the same time is (to my mind) the ultimate.

If you were going to introduce tabs at the top, I'd personally prefer if they were for repositories so that I could track multiple repos in one window.

I thinking about tabs at the bottom.

Moving between the tab bar at the bottom, the tabs in the middle, and the toolbar/menu at the top is a lot of mouse activity to navigate where you need to go. Having one bar at the top and one bar in the middle is better than having three bars, IMO. Tabs placed beneath their panes are not so common in UIs.

Maybe a column of tabs (Graph, Commit, Console) on the left side of the window, aligned to the top. That'd keep everything close together.

Consider using a docking framework so users can configure the layout to suit them. I don't think it's possible to please everyone with a single layout. Again, I like seeing the graph while I commit.

I actually don't like the proposal... For me it would mean constantly resizing panels (the splitters).

Perhaps a better UX could be achieved with docked windows like in the VS (refer to https://github.com/gitextensions/gitextensions/issues/3679).
But (there always has to be one) it won't work for non-windows users....

Maybe a "poor mans" docking solution where the user could select a layout from a predefined set of docked or undocked layouts would be possible? Finding a framework that will support docking for everyone might be hard?

I added some related issues:

4033

4031

Suggestions in #4031 that should related to the "modeless commit" similar to mockup by @drewnoakes
I agree to some extent with @RussKie and believe basic commit should be modeless, but "full" commit could be done in the popup

• Commit tab is currently hidden. Should have similar info as the commit tab for HEAD, except that there is no commit hash and that commit message is "current WIP" (what has been preliminary added).

• Enhancement: Editable commit text. Even if it only is possible to commit from popup dialog, it will simplify writing the commit message.

• Enhancement: Commit buttons similar to Commit popup

• Diff tab, file view context menu to stage/unstage and reset files

  • Should double-click a file work as in Browse (File History) or stage/unstage as in Commit?

• Enhancement: Separate tab so Commit/Diff can be seen simultaneously

  • Sufficient with moving the commit window?

What do you think of an idea to have commit dialog "dockable" at the bottom of commit graph (like @drewnoakes mockup) and dock/undock keyboard shortcut could be the same (or configurable) as opening the dialog in the first place.
So say you open the full-blown dialog with ctrl+space but want it smaller, ctrl+space again and it's docked. And the reverse if the last dialog state was docked.

@drewnoakes do you have a working prototype? I'd love to start using this TODAY :D

I started to implement using the CommitInfo tab in the beginning of the year, but it basically duplicated all code in FormCommit so that solution would not be fun from maintenance perspective and I dropped it.

Any thoughts on leaving this dialog as a modal but with an option to dock/undock it?

Never used it. It is MIT licensed. https://github.com/dockpanelsuite/dockpanelsuite

Closing this in favour of #5535.

In my personal opinion, it would have been better to implement this, anyway, there is a workaround, at least under Windows, that is to open folder in file explorer, right click and select "GitExt Commit...", this will open the commit dialog independently to any other Git Extensions window opened.