Allow running a custom Gitu startup command from the CLI

[frank-lenormand]

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!

[altsem]

I once had a gitu log, but dropped it while refactoring some time ago. The CLI could use some love, but I like the idea of having a git-like interface.

Maybe for a starter do: gitu log gitu log <REF> ?

Should also fix gitu show, which doesn't show HEAD per default.

Is the ui supposed to exit right from the log, or take one back to the status page when exiting?

[frank-lenormand]

I don’t particularly like the idea of Git UIs keeping a 1:1 equivalence with Git itself, CLI-wise. I generally do not get much more out of the $GITUI <subcommand> command that I can already get from git <subcommand>.

So, in my opinion, it’s preferable to create a pass-through Gitu command (cmd example in the first message) that may comply with the Git CLI, and let commands in the root Gitu namespace be called whatever is appropriate — even if that results in root command names colliding with Git command names, although it’s probably best to avoid that confusing co-habitation of e.g. gitu log and gitu cmd log.

I don’t know Magit at all, and I understand it’s supposed to be a source of inspiration or soft-reference in terms of design decisions, so sorry in advance if my issues miss the mark!

I’ve been using Tig for a while, and there are two features I appreciate:

1. Tig can display the Git log in its own list view, up to/from a certain commit (tig <rev>, tig <rev>..), similarly to git log <rev>, git log <rev>...

   If Gitu were to implement this like any other Git UIs, this would translate into gitu log <rev-range>. I think this could be supported, but it feels like there’s a missed opportunity to make the name more explicit, and abstract the range syntax behind command-line flags:

   gitu show-log --from <rev> (for git log <rev>..) or gitu show-log --to <rev> (--to being the default is not mentioned, equivalent of git log <rev>)

   Using either command line flag with a revision range would produce an error.

   When the Git CLI is not followed strictly by its UI wrapper, the above is possible. Otherwise, users must learn how to write revision ranges, understand the Git equivalent of running any subcommand using the UI etc.

2. Tig will display all the commits that modified a given file-path. As far as I know, it doesn’t support passing the path to a file that has been removed/renamed in a subsequent commit. It also keeps information related about file-changes (list below) segregated from each other, likely because it tries too hard to follow the Git CLI.

   So I think there’s an opportunity to create a command that handles that, and allows glueing together:

   • file path history (i.e. handle deleted/renamed files)
   • regular commit history (i.e. patches applied to files)
   • line-specific commit history (git blame but also making Git track lines being moved around git log -G)
   • various Git-related metadata, such as the tags surrounding a particular commit

   I don’t know what that command would be named, only that it would be a combination of various Git commands that can only be achieved by using those as building blocks.

Is the ui supposed to exit right from the log, or take one back to the status page when exiting?

Maybe a command line flag could be introduced that quits Gitu whenever the command/view it was invoked with is quit?

$ gitu --quit <cmd>
# Hit `q`, Gitu quits

Default behaviour:

$ gitu <cmd>
# Hit `q`, the parent view is displayed

Name of the flag to be determined :)

[altsem]

No worries, it's good to have some ideas and feedback!

it’s preferable to create a pass-through Gitu command (cmd example in the first message) that may comply with the Git CLI

This could be a lot of work. Some commands utilize git directly, but all that involve reading information use libgit2 (log current does). So someone would need to programmatically map all commands to that library anyway.

From what you suggested previously:

Map out the submenus to a CLI subcommand automatically. sounds a lot easier! And perhaps intuitive.

I haven't thought about ranges vs --from / --to much, one thing that pops up though is that in magit, you can do log other and enter a commit/range in a prompt.

We may want to support that in the future while inside the TUI.

I see what you mean about keeping things under cmd to keep things from colliding (especially if we're ever to allow users to define their own submenus etc, although I'm not sure we'll ever get there).

Not sure if there's any benefit of doing either: gitu cmd log current gitu --cmd "log current"

[altsem]

@frank-lenormand I started working on a module to parse key input, this'll be needed for supporting configurable keybinds. When it is done, it'd be really easy to implement your first suggestion (gitu -k ll). It doesn't prevent further additions to the CLI, and gets the job done. :)