Describe the solution you'd like
Would be nice to recreate the add all behaviour with, perhaps, shift+enter.

in the logview right now only tag will show up and its even pretty random which one.

One of the main goals of gitui is to not require the user to learn cryptic hotkeys/shortcuts to work with it. The command bar (at the bottom) always shows what actions are available in the current context.

That said:
Right now, in certain views the command bar is already quiet full and especially crowded when using a small/narrow terminal.

some features right now are not tackled because of this:

• #82
• #44
• allowing to commit not only when in the staging area of the status view

one solution for this could be to automatically cut of the commands at the end and show a more [m] command that would popup something similar to the help but only with the available commands plus allowing to trigger them when pressing enter on one.

Any better ideas?

term is looking for a new maintainer

The author of the term crate does not have time to maintain it and is looking
for a new maintainer.

Some maintained alternatives you can potentially switch to instead, depending
on your needs:

• crossterm
• termcolor
• yansi

See advisory page for additional details.

Is your feature request related to a problem? Please describe.
I'm also using Fork, and the sudden change of policy doesn't really suit me so I was looking for an alternative. The feature I use the most was interactive rebase so here is my feature request :)

Describe the solution you'd like
Ability to have a list of commit that I can act upon (squash, reword etc…)

Describe alternatives you've considered
I'm not really good at git CLI, always used a UI so if gitui could become a fully featured Git UI, that would be awesome.

show tags in commit log

   for name in repo.tag_names(Some(pattern))?.iter() {
            let name = name.unwrap();
            let obj = repo.revparse_single(name)?;

            if let Some(tag) = obj.as_tag() {
                print_tag(tag, args);
            } else if let Some(commit) = obj.as_commit() {
                print_commit(commit, name, args);
            } else {
                print_name(name);
            }
        }

Describe the bug
gitui crashes with message 'invalid git path'.

To Reproduce
Steps to reproduce the behavior:

1. Use cargo install to install gitui on ubuntu 18.10
2. type gitui in the command line
3. Hit return
4. See 'invalid git path' and observe that the app is not started.

Expected behavior
The app opens

Desktop (please complete the following information):

• OS: ubuntu 18.10

1. extend async lib with something like reset_hunk (+ unittests)
2. integration into the UI should be straightforward and similar to how rest of files is already done

some question need to be solved for this:

• does the stashing happen in the status tab? or..
• we will need a new tab for the stash list anyway, is that the place to also save stuff to the stash? this would allow setting the options like include untracked files?
• if we stash in the status-tab, do we use a popup to ask for the options like that?

Is your feature request related to a problem?
Use Home, End, PgUp and PgDn keys in diff and log panes.

Describe the solution you'd like
Scroll to top, bottom and by screen's height.

Describe alternatives you've considered
E.g. like tig.

gitui closes with a panic when resizing the terminal to weird small width like below 15:

16:06:42 [ERROR] panic: PanicInfo { payload: Any, message: Some(Trying to access position outside the buffer: x=14, y=0, area=Rect { x: 0, y: 0, width: 14, height: 54 }), location: Location { file: "/Users/stephan/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.9.4/src/buffer.rs", line: 245, col: 9 } }
trace:
   0: backtrace::backtrace::trace_unsynchronized
   1: backtrace::backtrace::trace
   2: backtrace::capture::Backtrace::create
   3: backtrace::capture::Backtrace::new
   4: gitui::set_panic_handlers::{{closure}}
   5: std::panicking::rust_panic_with_hook
   6: _rust_begin_unwind
   7: std::panicking::begin_panic_fmt
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panicking.rs:332
   8: tui::buffer::Buffer::index_of
   9: tui::buffer::Buffer::set_stringn
  10: tui::buffer::Buffer::set_string
  11: <tui::widgets::tabs::Tabs<T> as tui::widgets::Widget>::render
  12: tui::terminal::Frame<B>::render_widget
  13: gitui::app::App::draw_tabs
  14: gitui::app::App::draw
  15: gitui::draw::{{closure}}
  16: tui::terminal::Terminal<B>::draw
  17: gitui::draw
  18: gitui::main
  19: std::rt::lang_start::{{closure}}
  20: std::panicking::try::do_call
  21: ___rust_maybe_catch_panic
  22: std::rt::lang_start_internal
  23: std::rt::lang_start
  24: _main

currently this is one of the blocking operations that takes ~1s on large repos (tested on linux)

Is your feature request related to a problem? Please describe.
I sometimes want to stash only parts of files - for example some dirty debug code when mixed with "real" changes, when I might want to recover the debug code after testing the change without.

Describe the solution you'd like
When selecting changes to stash, allow selecting individual parts of files to stash rather than stash everything, like git stash push --patch.

Describe alternatives you've considered
Not using gitui for this. :-)

Is your feature request related to a problem? Please describe.
It can be useful seeing the branching/merging structure in the log view, in a similar way to git log --oneline --decorate --graph

Describe the solution you'd like
The graph view visible in the log window.

Describe alternatives you've considered
I haven't got any other alternatives other than not doing it. :-)

now that the diff and log component know their render height, we can make scrolling/selecting more natural by only scrolling once the selection would leave the view instead of always centering the view over the selection.

now that we have nice error coverage in asyncgit we could take the next step and add error support to the main application using anyhow based on the great summary on error handling in rust:

my idea would be to show an error popup similar to this one where ever possible: #74 (comment)

if we come across unrecoverable errors we might need to look into a second path aswell which will close the application.

MS announced a package manager: https://devblogs.microsoft.com/commandline/windows-package-manager-preview/

would be nice to be in there!
maybe it also allows being updated as part of our CD pipeline.

As I am not on windows, I am going to need help here :)

Describe the bug
It took me a while to work out how to change to the "Log" tab, as the key to press, tab, isn't mentioned in the help.

To Reproduce
Steps to reproduce the behavior:

1. Open gitui
2. press 'h' to view the help

Expected behavior
The help should show the key to press to change tab, (Something like "Change tab [tab]") probably in the General section.

Desktop (please complete the following information):

• OS: NixOS Linux
• Version 0.2.1

Is your feature request related to a problem? Please describe.
In the Log tab, I can see only the start of the log message for each commit, but when browsing the log I am likely to want to read the full message (or indeed view the diff).

Describe the solution you'd like
While browing the log, pressing 'enter' when an entry is highlighted could open up a panel showing more information - principally the commit message, but the diff for that commit would also be very useful.

Describe alternatives you've considered
An alternative could be a view like the main Status tab, with commits instead of files on the left, and a panel with the details on the right, showing the commit highlighted.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.

Since gitui has no configuration (yet?), this may be a bit early, but you're already on the wrong path:

to enable logging to ~/.gitui/gitui.log:

So please don't do that and use the XDG environment variables do determine where to put config, log and other files.

Additional context

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Describe the bug
In gitui-win v0.3.0 the Log tab is not updating after the first time the Log tab is opened.

The Log tab does not include the most recent commit when you make the commit with gitui or when you make the commit with another tool.

Tabbing to Status and back to Log does not make it update.

To Reproduce

1. Create new directory and cd into it
2. Run git init
3. Add a file to be committed (file.txt)
4. Open gitui
5. Add the file to the stage with the [1] menu
6. Make a commit with the Commit [c] option
7. Open the log and see the commit is visible
8. Again do 3, 4, 5, 6 with a second new file
9. Open the log and see only one commit

Expected behavior
When the Log tab is opened it updates the list completely.

Perhaps, it also would update after a few seconds like the [1] menu does with new files/changes.

Desktop (please complete the following information):
gitui-win v0.3.0

• allow moving cursor (see #117)
• show chars used (>50 red)
• support delegating commit msg editing to a terminal editor for longer messages

support adding untracked files in the changeset to ignore.
the more important question here is: how to add even more commands without flooding the quicker (bottom) - some context menu popup mechanism maybe?

calling the hooks is currently only implemented of *nix systems.
how does this even work on windows? does git call *.bat files? help of someone on a windows machine would be required here.

vs.

when in root:

Currently we can stage things only hunk by hunk or whole file at once. It would be nice to have ability to stage only current line or bunch of selected lines.

Flow would look like something like this:
We focus on diff panel and navigate to a hunk we want to work with.
Select lines we want to stage with arrows and some modifier key (is tui allow that kind of thing?) and press [S]tage button. If there were no selection stage current line.

Inspired by git-cola behavior, but it's a gui app.

1. show filename of file diffed in title
2. dont show 'no text file' as if it was a diff for binary files

currently it only include linux and mac.

Is your feature request related to a problem? Please describe.

Currently the main text color is yellow. Which doesn't read well on a white terminal background.

Describe the solution you'd like

A CLI flag to switch to a dark color theme for better readability.

Describe alternatives you've considered

• I don't know if it's a good idea, but simply inverting all colors might be enough
• Full blown (custom) theme support
• An environment variable or a configuration file are viable alternatives to CLI flags

Additional context

Describe the bug
In gitui-win v0.2.6 the Log tab shows nothing when there is exactly 1 commit. When the second commit is added, both the first and second commit will appear in the Log when you go to the tab.

Furthermore, when there are 2 commits (for example "Initial commit" and "Add readme") the text in the top left of the Log tab shows "commit 0/1" instead of 2/2.

To Reproduce

1. Create new directory and cd into it
2. Run git init
3. Add a file to be committed (file.txt)
4. git add . and git commit -m "Initial commit"
5. Run gitui and press Tab to enter the Log page

(for me, it will show there are no commits)

6. Create another file, stage it, commit it
7. Run gitui and press Tab to enter the Log page

(for me, it will show both commits)

Expected behavior
When there is exactly 1 commit the Log page would show it, as well as the top left text would read 'commit 1/1'

My impression would also be that the 'commit x/y' message would show y equals the total number of commits, and x equals the (1-indexed) number that is currently highlighted, where the very first commit is 1 and the most recent is >1.

Desktop (please complete the following information):
gitui-win v0.2.6

I currently use lazygit, but have a few gripes with it.

I understand that this project is in very early stages, but I'd still want to try it.

Having linux builds like other rust tools would be great, thanks!

I started asyncgit crate ignoring errors unwrap is all over the place but the goal would be to handle them correctly like with sync::get_commits_info

Describe the bug

failed to compile gitui v0.2.5 on Ubuntu 20.04 on WSL 2

To Reproduce

run cargo install gitui

errors in the log:
error[E0658]: use of unstable library feature 'matches_macro'

Expected behavior

cargo install gitui should work as documented.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 10 + WSL 2 + Ubuntu 20.04 LTS
• Version: gitui v0.2.5

Additional context
Add any other context about the problem here.

error[E0658]: use of unstable library feature 'matches_macro'
   --> /home/emv/.cargo/registry/src/github.com-1ecc6299db9ec823/gitui-0.2.5/src/components/changes.rs:140:17
    |
140 |                 matches!(tree_item.kind, FileTreeItemKind::Path(_));
    |                 ^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/65721

error[E0658]: use of unstable library feature 'matches_macro'
   --> /home/emv/.cargo/registry/src/github.com-1ecc6299db9ec823/gitui-0.2.5/src/components/statustree.rs:199:12
    |
199 |         if matches!(item_kind,  FileTreeItemKind::Path(PathCollapsed(collapsed))
    |            ^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/65721

error[E0658]: use of unstable library feature 'matches_macro'
   --> /home/emv/.cargo/registry/src/github.com-1ecc6299db9ec823/gitui-0.2.5/src/components/statustree.rs:217:12
    |
217 |         if matches!(item_kind, FileTreeItemKind::File(_))
    |            ^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/65721

error[E0658]: use of unstable library feature 'matches_macro'
   --> /home/emv/.cargo/registry/src/github.com-1ecc6299db9ec823/gitui-0.2.5/src/components/statustree.rs:218:16
    |
218 |             || matches!(item_kind,FileTreeItemKind::Path(PathCollapsed(collapsed))
    |                ^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/65721

error[E0658]: use of unstable library feature 'matches_macro'
   --> /home/emv/.cargo/registry/src/github.com-1ecc6299db9ec823/gitui-0.2.5/src/components/statustree.rs:226:19
    |
226 |         } else if matches!(item_kind,  FileTreeItemKind::Path(PathCollapsed(collapsed))
    |                   ^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/65721

error[E0658]: use of unstable library feature 'matches_macro'
   --> /home/emv/.cargo/registry/src/github.com-1ecc6299db9ec823/gitui-0.2.5/src/components/statustree.rs:300:16
    |
300 |             if matches!(item_kind, FileTreeItemKind::Path(PathCollapsed(collapsed)) if collapsed)
    |                ^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/65721

error: aborting due to 6 previous errors

For more information about this error, try `rustc --explain E0658`.
error: failed to compile `gitui v0.2.5`, intermediate artifacts can be found at `/tmp/cargo-install1l61u0`

Caused by:
  could not compile `gitui`.

based off of #43 there is still the open issue of how to support different key bindings like vim,emacs and nano. I need input on those, cause I don't use them at all.

The most flexible solution would be having gitui dump the default bindings into a config file (on first run) and load it on startup so people can alter it.

My plan is to do it in 2 bigger changes:

1. make key bindings dynamic

• refactor the key constants into a type KeyBindings
• change all the pattern matching on CT constants for the bindings currently to be done using runtime variables from the KeyBindings
• refactor commands::CommandText to be dynamic since they reference the keys

2. allow changing the bindings

• enable serde feature in crossterm to be able to serialise them
• use ron to load/save KeyBindings

Describe the bug
program crashes when showing help if terminal height is less than help modal height

To Reproduce
Steps to reproduce the behavior:

1. run gitui
2. change the height of the terminal to a very short height (ex 15 chars)
3. press h to display help

Expected behavior
A warning about the terminal height maybe but no crash.

Desktop (please complete the following information):

• OS: Windows 10 / Debian
• Version: master branch

Additional context
This is an issue when the tool is used in integrated terminals inside IDE where the user might resize the terminal often.

revert 72a1f94 once Crossterm issue is fixed: crossterm-rs/crossterm#421

Is your feature request related to a problem? Please describe.

I'd like to set the tool up so that when I right click on a directory (in windows) it launches gitui in the clicked directory. To do this I'd need a way to open the program in a different directory.

Describe the solution you'd like

gitui.exe --cd=projectdir to open the tool in the directory called projectdir

Describe alternatives you've considered

The context menu works fine from inside the directory, but with git bash I'm used to clicking on a directory to open that tool, so it would be nice if this tool mirrored that behaviour. This is a low priority thing.

Additional context

Describe the bug
When using the app on Ubuntu 20.04, in either view, pressing "h" for help causes the application to exit with exit code 101.

Running under strace, it doesn't look like anything bad happens - there are no signals and then something calls exit_group(101).

To Reproduce
Steps to reproduce the behavior:

1. Install Ubuntu 20.04
2. Download Linux release 0.2.5 from Github
3. cd to some git working directory and run gitui
4. Press "h"

Expected behavior
Some kind of help message should appear, I guess?

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• Version 0.2.5

use notify to watch git instead of permanent polling

one of the threads tries to send during shutdown when receiving side of channels closed already -> panic

for some reason only happens on windows

net2 crate has been deprecated; use socket2 instead

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.

• cargo publish
• test that cargo.toml version matches tag

Describe the bug
In gitui-win v0.2.6 after staging, and after writing a commit message, pressing Enter abruptly closes the gitui.exe window. Inspecting the repo after shows that the commit is not made.

To Reproduce

1. Create new directory and cd into it
2. Run git init
3. Add a file to be committed (file.txt)
4. Run gitui.exe
5. Press enter on the file in the unstaged menu
6. Press 2 to enter the staged menu
7. Press Commit [c]
8. Enter a message
9. Press Commit [enter]

Expected behavior
The commit should be made and the ui would update to reflect that without closing.

Desktop (please complete the following information):
gitui-win v0.2.6

Is your feature request related to a problem? Please describe.

The UI doesn't really tell that you can use 1-4 to switch between panels. There is a number behind the panel's title (Unstaged Changes [1]), but that could also be the number of unstaged files.

Describe the solution you'd like

Lazygit does a pretty good job at it: The bottom panel says: 1-5: jump to panel, […].

Describe the bug
In gitui v0.3.0 the commit function does not allow a commit to be made when the user has a user.email defined and no user.name defined.

It took me a while to discover that there is a difference between user.name being defined as empty (git config user.name "") and it being undefined (as in, git config --list does not show the entry at all).

In the empty case, interestingly enough, git commit does not allow the commit to be made, likewise gitui does not allow it.

In the undefined case, git commit does allow the commit to be made (and I think it shows unknown in that field in later git log or git show calls). This is where the gitui behaviour is different, as gitui does not allow a commit to be made with this message:

 Status   |   Log
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
┌Unstaged Changes [1]──────┌Error──────────────────────────────────────────────────────────┐───────────────────────────┐
│                          │commit failed:                                                 │                           │
│                          │git error:config value 'user.name' was not found; class=Config │                           │
│                          │(7); code=NotFound (-3)                                        │                           │
│                          │                                                               │                           │

Expected behavior
gitui would allow a commit to be made and fill in unknown as git commit does.