Give users more control over command args

[jesseduffield]

Is your feature request related to a problem? Please describe.
Lazygit currently runs some git commands with arguments applied that we consider to be sensible defaults. But different situations call for different args and users need a way of controlling the flags that are used.

Describe the solution you'd like
I don't have a good solution for this worked out in my head. We could learn a lot from observing how magit goes about this, but I haven't dug into that myself enough to know how much we want to emulate it. I want lazygit's main focus to be about making typical actions easy and fast, so if every action now costs an extra keybinding because we have to show a separate menu when they can configure command args, that's not worth it.

But I suspect there is a sensible middleground we can find.

Part of the solution will be to extend the functionality of our menus so that you can toggle flags / cycle options using keybindings associated with those options. Currently our menus only support selecting a single item and invoking it.

Describe alternatives you've considered
Luckily, custom commands can fill most of the current gap, with the caveat being that they can't be configured at runtime and that we don't have a menu view that supports toggling flags or cycling through a bunch of options.

[jesseduffield]

An idea that just came to me: what if we had a keybinding for switching to 'complex' mode such that any command you run pops up an args menu allowing you to configure the args before confirming the action.

As an example if I want to push with the --tags arg I could:

• press ctrl+i (arbitrary keybinding) to switch to complex mode
• press shift+P to push
• args menu appears which lets me toggle push arguments (we'll need to add support for this kind of menu)
• press 't' to toggle the --tags arg (or navigate to it and press enter on it)
• press enter to confirm the args and push
• lazygit runs git push --tags.
• Press ctrl+i again to toggle out of complex mode

This approach is good because:

• it doesn't slow down users who don't need the finer-grained control
• it lets you continue to use the same keybindings for existing actions rather than having some other keybinding for a fine-grained variant

Downsides:

• like all modes, it requires you to know it exists in order for you to use it i.e. it's not very discoverable.

Tricky parts:

• I think that in complex mode we should show the menu for all actions even if it's just to say that 'this action is not configurable'. That way the user doesn't need to worry about whether an action is configurable or not because there will always be the extra confirmation step
• Do we keep track of the fact that the --tags arg is toggled on for git push? Do we enable that flag next time the args menu appears, and if so do we persist the args across lazygit sessions?
• If we do persist args, do we apply them when not in complex mode?
• There are situations where lazygit depends on certain flags being passed, or things being done in a certain way. For example, our cherry-pick action doesn't even do a cherry-pick, it does an interactive rebase instead! What do we do if a user wants to configure cherry-pick to use a specific flag? Allow them to do it but warn that it's not going to be the same as if they had used the non-configured version? Or just disallow it?
• What do we do with existing situations where two actions only differ by a flag? E.g. simple rebase vs interactive rebase. Do we keep the two options for convenience or have a single rebase command which can be configured as interactive via complex mode
• I don't like the name 'complex mode', it's more like 'arg configuration mode' or 'fine-grained mode' but we can worry about naming later.

Above I'm talking about configuring actual git CLI args, mostly because that's the majority of existing use cases. But we don't need to be limited to CLI args, we could add any random configurable thing here that relates to the action.

[jesseduffield]

@stefanhaller @mark2185 @AzraelSec @peppy keen to get your thoughts on the above

[mark2185]

There are situations where lazygit depends on certain flags being passed, or things being done in a certain way.

I think this was one of the bumps the last time this was discussed that some of the commands lazygit offers aren't really mapped 1:1 to what is going on behind the scenes, but I don't see how we can both have the cake and eat it too.

That and the fact the actual command is being generated right before it's actually going to run (depending on configuration options), so it's a tad difficult to append custom flags to something not quite baked yet?

I may be remembering wrong, tho.

It does sound easier (albeit more hands-on) to offer some toggleable options for common operations and then extend the support every now and then. We can always have beta testing to see if we're on the right track? :)

Given enough time and reasonable defaults, I see no reason why would we need both "simple" and "complex" mode. If all the flags have their explanations, there are only upsides.
I do get that one tool can never fit both a newbie and a poweruser, but a plethora of bells and whistles with sufficient explanations could be good for both?

[stefanhaller]

I like the idea. However, instead of making it a mode I would try to make it more of a chord, where it applies only to the next command you issue; maybe even with a timeout of one or two seconds. This seems more convenient to me, as in most situations you only want it for one command, not for several in a row.

• Do we keep track of the fact that the --tags arg is toggled on for git push? Do we enable that flag next time the args menu appears, and if so do we persist the args across lazygit sessions?

I see that this might be convenient for cases where users always want to use the same custom flags, e.g. for merge --no-commit; but I don't consider it essential, and would recommend to not do it for an initial version, for simplicity.

• If we do persist args, do we apply them when not in complex mode?

Definitely not; this could be surprising. Consider for example that the user wants to do a one-off commit bypassing hooks, so they to ctrl-i, c and turn on the "--no-verify" toggle. It would be unexpected if, from then on, all normal commits would bypass the hooks, without the user even realizing this.

E.g. simple rebase vs interactive rebase.

For this particular example I'd like to keep both commands. I use them both regularly, and having to go into the advanced mode panel to toggle an option for one of them would be a step back in convenience.

One thing I'm not totally sure about is whether it will work to make actual git flags toggle-able. It might be better to provide more high-level options (e.g. "skip hooks" instead of "--no-verify"). But I guess it needs a complete assessment of which commands would be affected, and what their options would be, in order to decide this.

Given enough time and reasonable defaults, I see no reason why would we need both "simple" and "complex" mode.

The main benefit of the "complex" mode for me is that we can use it for commands that don't have a menu now. If you just add toggleable options to all commands, you can only do it for commands that already show a menu, or a confirmation.

[AzraelSec]

I'll try to offer a different point of view. Looking at the issues, I see two patterns:

1. Additional commands - e.g. Merge squash #2028
   The line between a custom command and an integrated one is based on how widely it is used.
   We can continue working on the issues that pop up and evaluating each time if what has been requested is "common enough" to gain a place inside the UI (like for the advanced vs simple rebase, IMO) or if it's more appropriate for a user to define its custom command. We'll never be able to satisfy the necessity of each developer, per project - we should focus on covering the most common paths. The complex mode would solve this issue, but would it be that much different from opening the editor and adding a custom command? And if we don't persist the flags configuration, is it a better UX?
2. Integrated commands don't fit - e.g. Default rebase arguments are sub-optimal #2772
   Even in this case, a custom command would solve the issue, but I get it's uncomfortable to create a custom command to substitute the default action. We should try to keep the set of flags used in the integrated commands as small as possible and allow the users to define a superset of them. Alternatively, a way to override the commands the menu items run, possibly per project (so that you can follow different conventions), would do the trick.
   The complex mode would also do, but only if we persist the flags configuration. And in that case, we're just overriding the default behaviour programmatically, aren't we?

I think, in the case of a particular command to run once/rarely, executing it on the fly using the custom command view is acceptable and optimal.

I get the point of the complex mode approach - I'm just asking whether it's worth the effort.

[peppy]

Speaking only for my specific issue (#2772), I guess the weirdness for me is what has already been touched upon by others above – lazygit is adding flags which are assumed to be sane defaults, but because this differs from raw git commands (which some of us have used for years/decades) this can be uncomfortable. I think this particular kind of case could be solved with a config toggle explicitly for it, rather than a complex mode or flags toggle dialog.

But I can understand the consideration of such a UX for the more broad picture. I'm just not sure it would handle the case where a user always wants one particular flag removed from a command like rebase.