Call for co-maintainers

[extrawurst]

I want to scale work on GitUI better. Over the years I have been a driver of this project but also a single point of contention. This can be improved.

Calling for co-maintainers is open to everyone who contributed before but also to everyone willing to join.

The three levels/ranks of roles

1. become a contributor, there is plenty of simple topics to jump on marked as good-first-issue, join the gitui channel on discord
2. become a reviewer and join the internal discord channel
3. become a co-maintainer with merge rights

How to become a reviewer?

• have at least one PR contributed/merged
• have at least one PR of someone reviewed and coached to the point of mergability

Aside from that just ask me and show interest to gain this status. I will invite you to my discord and invite you to the project as reviewer.

How to become Co-Maintainer?

That one is less clear defined but basically means repeated contribution via code and/or reviews. But mostly requires good communication in between, dependability and continuity.

FAQ

Do I need to be great at Rust?

No I am sponsoring beginners work via Draft-PRs and feedback, reviews. Just show the dedication and I will help where I can.

I have not a lot of time but would like to help?

Thats alright, any help counts, see above: As long as communication is good and I know when and when not to depend on you we can make it work. We all have a life :)

I don't have time to code at all or to review code, can I still support?

Absolutely - spread the word!

• Post on the various channels that you use GitUI
• Share our release messaging
• Jump officially into the role of the GitUI release PR: #1728

Lets drive GitUI to 1.0 and beyond! ❤️

[adamconkey]

I've started using GitUI recently and love it! I'd like to try to help out if possible, I'll poke around in the starter issues and see if there's something I might be able to help with.

[tkr-sh]

Hello hello! :)

I've created a PR because I personally wanted to add quick support/access to conventional commits, with some extra emojis inspired by gitmojis! By doing so, I noticed quite a few possible improvements to the codebase, that make the actual coding pretty bad at times. All of these issues are - at least to me - some flaws in the design of gitui. If you agree with it @extrawurst, I'm ok to do the fixes for the following points. But, since I'm also a daily user of gitui from quite sometime now, I'm also willing to help whenever I can.

Here are my ideas:

Things to fix in the codebase

Use global data with Lazy/Once (or similar) rather than passing everything in parameter

In the code, there is a lot of repeating data.

You'll often see struct that herits from fields of Environment. Why not just create some global / shared data that can be accessed from everywhere without having to pass it everytime in parameter ? And even tho Rc::clone are really cheap, when you do that 50 times, it's more than zero (<=> not optimal => not as blazingly fast as possible).

Key

I think that there is a fundamental problem with how keys are handled in gitui.

How they are handled for now, is by using a struct of almost 100 fields with the same exact types. It's not really good in term of code since you could just use a HashMap<EnumOfPossibleFields, GituiKeyEvent> instead.

Why ?

For 2 reasons:

• You can "easily" get all the mappings of a Key. (good luck to do that with 100 fields)
• You can match by getting the different mappings of a key instead of if/else if/else

For those that don't know, the event handling for now is very suboptimal, its a if... if else ... if else (number of events times) else for all the events. Using a Map + match will:

1. Drastically improve performance
2. Increase a lot the code readability

Split files

I think that constantly having files of 600-700 lines is not a good thing, nor that it scales well.

But, it's often the case in popups for example. I think that this should be refactored into multiple files for the majority of the popups.

2 keys one mapping ?

With the new way that I previously describe to handle keys, it will be possible to assign 2 keys to one action (e.g. ArrowUp and k for a theoretical Event::Up) for example. This will be a nice feature to have so that there can be some good default Vim keybindings out of the box while keeping the more "user friendly" keybindings.

Hiding components

For now, we call draw AND event for EVERY popup on each cycle. This seems to me to be really suboptimal, since in my opinion, we should store in a central place which popups should be rendered rather than letting that to each popup.

This means =>

• Less complexity on every popup struct
• Less functions to call
• Generalized way to handle visibility

There is also a similar problem with async events, that will call .update_git 15 time every time there is a git event.

deny(dead_code)

I don't understand that. It makes prototyping really annoying. Like I could understand that this is because you don't want to push bad code, and I understand that, but don't you do that for all warnings ?

No workspace

I think that there are no good reasons not to use workspace in this scenario.

One config file for all

I think that it would be great to have one config file for everything.

Currently there are 2 files: ~/.config/gitui/theme.ron and ~/.config/gitui/key_binings.ron. But actually, I think that there should be at least a third one to customize more things like, tab order for example, layout of git interface, display or not of help bar at the bottom, and also, people should be able to opt-out of ghemoji feature even if they compiled the program with the feature for example.

Therefore, I think that it would be better to allow everything to be configured in just one file.

Improvements I want to make

Rebase interactive

It seems to be a pretty important feature for most users, and I agree with that. Because handling rebase in gitui for now is not that good. I think that I could do a somewhat correct implementation of it. So I'll probably work on it when - and if - the important points above are resolved.

Selection in the 1 Status tab

I think that it would be cool to select multiple files in 1 status.

(Maybe remove 4 Stashing once this is mature ?)

Integrating with Lua

This one might not make the unanimity, but I think that it would be a really nice thing if users could write some basic lua scripts that interacts with gitui. This would allow a lot of customization. With mlua, this is pretty easy.

Highlight char changes in a line

Sometimes in a line change, there are not a lot of changes.

Example:

- println!("Hello world");
+ println!("Hello world!!!");

In this case, I think that it would be a good thing to highlight !!! differently, so that it's clear what changed.

Syntax highlighting of diff

I think that it would also be nice to have syntax highlighting on the diff. Or at least, to be able to decide if we use it or not. (Cf. new config file above)

Other

Notes on my frequency of contribution

I have a lot of other projects that I'm working on, and I also have a fulltime job, so I don't know if I will be able to dev a lot, but at least, I'm here to help on the points above :)

Notes on what ~I like and what~ I don't like

I don't like macOS and Windows. Therefore, I won't handle any PR related to specific problems of these OSes.

I don't like discord. Therefore, I won't join the Discord "server".

What about License ?

I'm not sure why this project has been licensed under the MIT.

I think that it would make sens to relicense it under GPLv3 or AGPLv3 since I don't think that anybody wants the code of this open source project to become proprietary one day (compared to projects like smartgit). And since this is not a library, I think it's ok to use GPLv3 or AGPLv3!

[Joshix-1]

Use global data with Lazy/Once (or similar)

Since 1.80.0 rust has LazyCell

And since this is not a library

There are multiple libraries in this repository. https://crates.io/crates/asyncgit https://crates.io/crates/scopetime https://crates.io/crates/git2-hooks https://crates.io/crates/invalidstring https://crates.io/crates/filetreelist

[tkr-sh]

Since 1.80.0 rust has LazyCell

Yup! This is why I'm saying that. But for now the MSRV is 1.70 for now. Tho, there are still some crates that allow doing that in 1.70

There are multiple libraries in this repository.

In this case, I was talking about gitui. And it's totally possible to license gitui under GPL and having other libs staying in MIT.