altsem / gitu Goto Github PK

It would be very helpful if there were binaries available for download so you don't need to install the Rust toolchain to install gitu.

I'd be happy to submit a PR for this as I've gone through the process a few times with my own projects if this would be accepted

Currently it's possible to apply / reverse changes while looking at a commit using s (stage) and u (unstage).
This has some undesired effects though, as they leave unstaged and staged changes.

Implement a and v as in Magit.
Disable s and u while looking at logs/commits for now. (Magit lets you do this.)

Hi @altsem, gitu looks fantastic. Would it be possible to support using an external tool to add colors to diffs before display? I'm the author of https://github.com/dandavison/delta, and I'd love to be able to use gitu with colors supplied by delta. Delta works by taking diff format input on stdin, and writing the same diff to stdout with ANSI color escape sequences inserted. It has an option --color-only that guarantees not to make any structural alterations to the diff, other than adding colors (syntax highlighting and/or background colors). So the simplest implementation would be to allow users to configure an external binary that is passed the raw diff as text, just before gitu is ready to display it.

(Incidentally, delta can be used in this way to add syntax highlighting and colors to emacs magit, but of course the implementation there is more complex because the ANSI color escapes produced by delta have to be translated to the way emacs represents colored text: https://github.com/dandavison/magit-delta.)

Title says it all. Program should probably exit gracefully if it can't find EDITOR, at minimum. It could also look at a few other ENV vars before giving up, such as:
VISUAL: This variable serves a similar purpose to EDITOR. It's typically used by programs that require a text editor to launch in a graphical environment. If both EDITOR and VISUAL are set, programs often prioritize VISUAL.

GIT_EDITOR: Git, a widely used version control system, allows users to specify a separate editor specifically for Git operations using the GIT_EDITOR variable. If set, Git uses this editor instead of the default editor specified by EDITOR or VISUAL.

SUDO_EDITOR: When users execute commands with elevated privileges using sudo, the SUDO_EDITOR variable specifies the editor to use for editing files. It overrides both EDITOR and VISUAL for sudo commands.

Gitu should be configurable. Keep a file in ~/.config/gitu/config.toml or equivalent.

Start with colors (readable diffs is important)

The confirmation prompt seems pretty prevalent in Magit, but currently it's implemented as a hack in Gitu. The tui-prompts library recently introduced should help with this. (Have a look at the CheckoutNewBranch Op).

Dicard menu (K)

Gitu doesn't prompt you like Magit does, rather requires the cursor to be on whatever you want to check out.

Magit deals with checking out by prompting which branch/ref to use first (defaults to currently selected).

On my work mac I have $EDITOR set to /Applications/MacVim.app/Contents/MacOS/Vim -v which is MacVim. gitu does not understand this correctly because it assumes that the content of $EDITOR is a path to an executable and nothing else. It should parse this content properly and invoke the command correctly.

Thanks for sharing gitu, I love it so far!

When I'm working on a branch that only exists in my local repo and use Magit to push, Magit handles creating the new branch at the destination and setting that branch as the upstream of my local branch. I'd like gitu to do the same.

My favourite magit feature is the ability to individually stage lines. This tool only seems to let me stage stuff down to the hunk and I'd like for it to allow drilling deeper!

Inside magit, you can open a hunk and then enter visual mode and select lines.

Can you make release to crates.io?

Gitu currently only looks at the workdir when opening files mentioned in a diff.
Instead, get the content from git and open that instead.

Tested this out in Magit:

• Selecting the entire hunk or file takes you to the "new" file.
• Selecting an added or unchanged line takes you to the "new" file.
• Selecting a removed line takes you to the "old" file.

At some point, it might be nice to make the calls to git push, git pull, and git fetch (anything that relies on the network) asynchronous! I'm stuck on a quite slow connection, so when I go to push my changes, the UI freezes up for a while!

I could just wait to do all of my pushing at once (after staging and committing everything outstanding), but it might be a nice quality of life feature to decouple the UI responsiveness from network access!

I tried installing gitu on Windows with cargo install --git https://github.com/altsem/gitu.git --locked, but it failed because the code uses signal_hook::iterator.

As per https://docs.rs/signal-hook/latest/signal_hook/iterator/index.html, signal_hook::iterator is not for Windows:

"Available non-Windows and crate feature iterator only."

The cursor should probably follow when scrolling, currently it remains in place.
How to deal with viewing long hunks? How does Magit handle this?

I know that, as a developer, I should probably avoid having my locale set to anything but C, however, I wonder if the tests could easily be tweaked to avoid relying on fixed English strings. Imagine those change between git versions, the tests would just stop passing.

For anyone having the same issue, this can be avoided by setting LC_ALL=C, like this:

LC_ALL=C cargo build

Hi,

I believe it’s not possible to override the Git commands run by Gitu (or defined new Gitu commands) from the configuration file:

https://github.com/altsem/gitu/blob/a0c2970/src/default_config.toml

This might be out of scope for the project, but I’d appreciate being able to define my own shortcuts, similarly to how I do it with tig.

Thanks!

Some commands like 'bb', 'lo' etc. should accept input after invoking. Currently, there's no such thing in Gitu. Also handling autocomplete inside it might get messy (skip in first iteration?).

As seen in Magit:

Can You push this repo to https://radicle.xyz/ too?

I am trying to install gitu from both cargo install and from git master, but both seems to fail with this error:

$ cargo install --git https://github.com/altsem/gitu.git --locked
    Updating git repository `https://github.com/altsem/gitu.git`
  Installing gitu v0.6.3 (https://github.com/altsem/gitu.git#60024baf)
    Updating crates.io index
error: failed to select a version for the requirement `chrono = "^0.4.34"`
candidate versions found which didn't match: 0.4.31, 0.4.30, 0.4.29, ...
location searched: crates.io index
required by package `gitu v0.6.3 (/Users/maxking/.cargo/git/checkouts/gitu-5e9804da17feeb18/60024ba)`

I looked up the latest versions of chrono on cargo index, which looks like is 0.4.35, but that doesn't seem to work either.

Hi,

It’d be convenient to have something like gitu --version, to know what version is currently in use.

HTH!

This could be solved by translating a line in a hunk into a line in a file:

    @@ -7,2 +7,1 @@
    -hello
    -there
->  +extra

..translates to line 7

    @@ -7,2 +7,1 @@
    -hello
->  -there
    +extra

..translates to line 8, although gitu doesn't display historical files at the moment. Just show the new file at line 8 meanwhile.

// Add this clause at src/ops/show.rs:16
// Some(TargetData::HunkLine(hunk, line)) => {
//     editor(h.new_file.as_path(), Some(*correct line goes here*))
// }

Hi,

When running an interactive rebase from the UI, it appears that Gitu runs git rebase --interactive <commit>, with commit being whatever reference was selected.

This results in the selected commit not showing up in the upcoming editor, which is surprising to a user unfamiliar with the underlying Git command.

Could we please make it so Gitu runs something along the lines of git rebase --interactive '<commit>^', instead?

I reckon this would open the door to further issues, for example if the selected commit is a merge commit, but the improvement would be appreciated in other cases.

Thanks!

Great project!

I believe for the median user a web-based manual would be appreciated, something like https://magit.vc/manual/magit/. You could host it on github pages.

I could get started on it (along with CI to build the page based on source files) if you have any preference on which tool to use.

Reproduction:

 danil   fix/stash-worktree  ~/offw/rust/gitu  echo "meowmeow" > cat.txt
 danil   fix/stash-worktree ?:1  ~/offw/rust/gitu  gitu -k "jsjKy<enter>"

Yields error:

I think we want to git restore --staged <file> followed by std::fs::remove_file(file), right?

Hiya! Thanks for the super cool looking tool! Unfortunately my main project at the moment is set up as a Git submodule of another repository, but it seems like something about that setup is confusing gitu and I'm ending up with the following error!

Error: Os { code: 20, kind: NotADirectory, message: "Not a directory" }

I was able to reproduce the error by creating an empty git repo (using git init) then using git submodule add ... and adding any other repository into it. gitu works in the parent directory, but cd-ing into the new submodule means that gitu returns the error above.

Let me know if you'd like any more information, and I look forward to using gitu soon!

When I try to run gitu, I get the below error.

user@macos:~/Downloads/gitu $ gitu
Error: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }
user@macos:~/Downloads/gitu $ 

• OS: macOS 14.2.1 (23C71)
• Version: cargo install --git https://github.com/altsem/gitu.git --locked # 6196acc

It opens up the editor, might be why.

Hi,

I often have to type l, l upon starting Gitu.

I’d like to be able to create a Git/shell alias that starts Gitu and makes it jump directly to the log view.

I’m not sure what form this would take, but I can think of a couple options:

1. Have a CLI option that allows Gitu to play arbitrary keys passed as parameter, on startup. Example: gitu -k ll would start Gitu, and automatically jump to the log view (by interpreting the two l).
2. Map out the submenus to a CLI subcommand automatically.
   Example: gitu cmd log current would start Gitu, which would know the intent is to enter the log submenu, then display the current commits. This would avoid having to rely on whatever keys are bound to which menus/options.

Thanks!

Found that a user had commented this, need to verify / fix it.

See https://github.com/martinvonz/jj

it has much more powerful primitive, better defaults and still compatible with git.

Any interest in packaging this in a Nix flake and/or package? It would make it much easier than toolchaining Rust.

Thanks for making this! I really like it, especially for when I need to work on Windows.

One of the features I like about Magit is its support for easily differentiating a branch's upstream/merge and pushRemote. I first saw the feature+workflow described here, and now I find other git UIs without this feature like vscode's to be lacking. It's very convenient to be able to quickly see both the difference between the upstream merge target (e.g. master) and the remote branch being tracked (usually a "feature" branch with the same name as the local branch). For example, with Magit when I run a fetch:

• I can immediately see if some other feature has been merged to master and my feature branch has fallen behind
• I can immediately see if someone else, working on the same feature as me, has pushed to my feature branch and it has fallen behind
• I can quickly pull either master or the remote tracked branch into my local branch

The main features from Magit that I'd like to see in this project:

• Support for the separate push/fetch/pull keybinds described here for pushRemote vs upstream/merge
• Support for the two sections in the main status screen showing the diff between the local branch and pushRemote, and the local branch and upstream/merge
• Support for automatically setting branch.<name>.pushRemote (if it's not already set) when using the "push to pushRemote" keybind, in the same way as Magit

I'm not sure how big of an ask this is, I haven't looked at the codebase yet, but I like the project and I like rust so I might try implementing this at some point.

With a clean working directory:
gitu -k 'll<enter>uqqzw<enter>'

$ git stash push --staged
error: patch failed: .recent-changelog-entry:1
error: .recent-changelog-entry: patch does not apply
Cannot remove worktree changes
! 'git stash push --staged' exited with code: 1

1. There shouldn't be any temporarily stashed things left over.
2. The error should trigger a refresh (now it only appears after pressing g, or some other action).

In Magit:

This should be relatively easy, all commands are dispatched via State::run_cmd / State::run_cmd_interactive

Search down/up in any screen.
Bind to / and ?, n and N to go to next/prev?

n is currently bound to moving the cursor down. May want to bind ? to help.
Does it make more sense to have separate vim/emacs-like keybind profiles?

It'd be useful to be able to copy a commit hash.
Select anything with a commit hash, press y and it would be copied to your clipboard.

y is already bound to show_refs in the current config, but I suggest moving show_refs to maybe Y.

Hi, I just found this project on the orange site and have been playing around with it and quite like it so far. One thing I couldn't figure out, and maybe it's not been implemented yet, is how to view a diff of one of the unstaged (or staged, or untracked) files.

Hi,

Whenever in a view that’s nested several submenus deep, I tend to hammer down the q (or esc) key.

If I hit the key one too many times, Gitu ends up quitting.

I would like it to (optionally) ask for confirmation before quitting.

Alternatives:

• Only quit if q is hit, not on escape.
• Have a separate key/combination that jumps back to the main menu (an unwind command)

Thanks!

Build support for passing flags to commands (for example git push --force-with-lease, or P-fp in Magit).

• Iterate on the Submenu ui layout of Gitu. Where do command flags fit in?
• Some arguments are enabled per default.

Thank you for your awesome work. I tried nerd-font(e.g. Jetbrains-mono-nerd-font) and non-nerd font, but none of them works. see the cursor in the following image.

In magit:

Unstaged changes (1)
modified   README.md…

Staged changes (1)
modified   README.md…

gitu currently shows:

Unstaged changes (1)
README.md…

Staged changes (1)
README.md…

Hi @altsem ! I could just be missing the option, but is it possible through the UI to create a revert commit?

I've seen there are a couple of reset options, but I don't know if those are quite what I'm looking for?

We'll want this in order to start doing releases.
Likely we'd need to commit to a commit format.

Investigate and implement tooling around this.

Gitoxide is a Rust-equivalent of libgit2 (currently used by gitu).
It may prove easier to use, as well at being fast at cloning large repos.

It is not feature-complete. But Gitu still currently falls back to CLI Git for things that don't involve parsing.

https://github.com/Byron/gitoxide

We're missing the stash list on the status page, as well as stash commands.

Start with save / pop / apply.
Some of these commands open up a prompt, like zz prompts you to name the stash.
zp will also prompt which stash to pop (default to 0, or the marked one).

Hi,

It’d be nice if Gitu supported worktrees.

Currently, running it in one yield the following error:

$ gitu    
Error: Os { code: 20, kind: NotADirectory, message: "Not a directory" }

In a worktree, .git is a file that contains the path to the parent repository.

The magit package allows you to do so by "staging" the heading itself, which stages everything under it. For example if changes are made to flake.nix and cargo.toml, pressing s on the heading "unstaged changes" will stage both files. You can also unstage all staged files in a similar fashion.