Review of version 1.4 beta

[Escain]

Hello,

First of all, thank you for this great and beautiful software! I enjoy working with it, and I am progressively replacing my previous Git client with it.

I especially like:

1. The history graph
2. Left view with branches, remotes, tags, stashes and submodules
3. The tab mechanism for multiple git repos
4. A Convenient "Terminal" button

I installed the version 1.4.0 beta to test new features, and I have seen no regressions or new bugs so far. New features that I have tested also seem to work well.

Consequently, and from my point of view, 1.4.0_beta is already better than 1.3.1.

---

I would like to take this opportunity to discuss a list of few feedbacks that I have noticed while testing, usually also present on 1.3.1:

1. Switching to origin/xxxxx shows "Ref xxx already exists" if the branch exists locally. I wonder if it would be a good idea to switch to that xxx instead of showing the error. Especially if both are aligned.

2. I still miss a better way to stage and discard changes:

   1. Discard all changes: It could be a button aside of "Stage All" (Discard All Button #224)
   2. Selectively discard/stage changes: I would like to be able to select several changes (files) and stage or discard them. (Select Multiple Changes #190)
   3. Improved per-line staging: (Per-line stagging should be more user-friendly #164)
   4. Generally speaking, I don't like that separated staged/unstaged GUI, and it seems much better to have just one with both.

3. No close button in "Action" popup: Esc allows to close it, but a way to do it with the mouse would be more coherent with the rest of the application.

4. Settings are applied imediately when changing a value. The "Accept" button lets to think that they are not applied until you accept the changes, and thuse, makes the user to look for a "Cancel" button. I would rename it to "Close"/ "X"

5. Title for the commit message: most Git clients have a separated "Title" input that is very convenient. I think that it's juste create the first line of the comment.

6. On windows, the "tree-view" of the staged/unstaged files seems different: On Linux I see a real tree with folders that I can fold/unfold. On Windows, I just see the relative path prepend to each file in the list.

[JetpackDuba]

Thank you for your feedback 👍

Switching to origin/xxxxx shows "Ref xxx already exists" if the branch exists locally. I wonder if it would be a good idea to switch to that xxx instead of showing the error. Especially if both are aligned.

Yep, this is would be part of #30. There are a bunch of "invisible" changes to handle this better. All these kind of error that have a "preferred solution" should have it suggested and, in some cases, mark that solution as the default behavior without showing the error. It's been tough because in many ocasions JGit just throws a generic exception type and manual parsing of the errors has to be done...

2. I still miss a better way to stage and discard changes

I haven't yet added it to the milestone because I have to re-organize the issues a bit but all the mentioned issues will probably be part of v1.5. The 2 main goals of the release will be improvements of the graph and how status changes are managed.

2.4 Generally speaking, I don't like that separated staged/unstaged GUI, and it seems much better to have just one with both.

Do you mean to have it like Github Desktop with checkboxes? If so, I don't think it's going to happen any time soon. While GH Desktop tries to hide some complexity, it's done by hidding useful information and make it behave differently than how does Git usually behave.

3. No close button in "Action" popup: Esc allows to close it, but a way to do it with the mouse would be more coherent with the rest of the application.

Most of the actions in the dialog should go away eventually (if not all of them), it's a bit of a workaround. But yes, I can add a more obvious way to close it. Clicking out of the dialog should also close it. Feel free to create a new issue :)

4. Settings are applied imediately when changing a value. The "Accept" button lets to think that they are not applied until you accept the changes, and thuse, makes the user to look for a "Cancel" button. I would rename it to "Close"/ "X"

Yes, it's intentional because not all the settings are applied immediately (everything with a text field is applied on accept). Originally, all the changes were applied only on save, but that was confusing to some users that some settings that affected the UI weren't applied at the moment (for example, the color theme).

5. Title for the commit message: most Git clients have a separated "Title" input that is very convenient. I think that it's juste create the first line of the comment.

Everything is treated as the message body, it's just a fancy way of some git clients. It can be added but I don't really see much benefit to it so it would be very low prio.

On windows, the "tree-view" of the staged/unstaged files seems different: On Linux I see a real tree with folders that I can fold/unfold. On Windows, I just see the relative path prepend to each file in the list.

I've created an issue for the 6h point, probably something wrong with the paths separation #235

[Escain]

Do you mean to have it like Github Desktop with checkboxes? If so, I don't think it's going to happen any time soon. While GH Desktop tries to hide some complexity, it's done by hidding useful information and make it behave differently than how does Git usually behave.

I am not sure to understand: to me, if we assume that a single file/line cannot be staged and unstaged at the same time, then having two lists or one single with a boolean to indicate whenever it's staged or not should be semantically equivalent. Or am I missing something?
Obviously, a file can be partially staged, and this is why files on (e.g. GH-Desktop) have a tri-state checkbox.

Yes, it's intentional because not all the settings are applied immediately (everything with a text field is applied on accept). Originally, all the changes were applied only on save, but that was confusing to some users that some settings that affected the UI weren't applied at the moment (for example, the color theme).

Hmm, what about making all of them applied immediately? For texts, it can be done by making a delayed saving:

• If the user closes the popup, or changes the tab, all unsaved changes are applied.
• While in the page, we wait (e.g. 1s) and if no new character is written in that time, the value is applied. If a new character is written in that lapse, we reset the timer to 0. This way, we avoid many updates.

Thank you again.

[JetpackDuba]

Damn sorry, I must have missed the e-mail notification.

I am not sure to understand: to me, if we assume that a single file/line cannot be staged and unstaged at the same time

As you mentioned, files can be both staged unstaged (I do it almost daily), so can lines. I'm not sure about the tri-state check, personally I see it as another abstraction of the file state in the repository. The current implementation makes it easy to switch from Git CLI and most other tools because of the same representation of the information.

In any case, I'll explore it further and consider it as alternative to the current version.

Hmm, what about making all of them applied immediately? For texts, it can be done by making a delayed saving

It could be a solution but, honestly, I don't think it's that big of a deal how it currently works. Perhaps in the future if most of the relevant gitnuro features/issues are completed.

Sorry again and thank you for your feedback.

[A-Metal-Penguin]

Just wanted to say thank you for this software! I really like it!

[JetpackDuba]

Thanks to you! I hope you keep enjoying it 😄