aphosis / gmux Goto Github PK

Some logs don't have a new line between the last line of a repository log, and the next repository log header.

Currently repositories without a HEAD ref cause a critical error in the discovery process.

They should be excluded, with a user warning.

Right now the settings are saved as extension-less files.

We should log a repository command output as soon as it is available, right now you have to wait for every repository to complete its command, which is a weird behavior for a logger.

gmux ref points to HEAD but a better option would be to have a priority chain:

• Tag
• Commit SHA
• HEAD

Currently gmux is also available as a library, and needs real API docs.

It should update the existing data, not override it.
We should be able to choose which fields we want to update.

Basically, I want to update the list of repositories (new ones, deleted ones), without modifying the branches for example

Use case: if I checkout a branch for a review, I don't want to write it to the configuration when I update the pool.

Right now the configuration file is looked up in the traditional application config dir (os dependent).

It would be nice to have an environment variable to specify an arbitrary configuration directory, as well as a command line argument to override it.

First and third party errors are treated the same, most of them bubble-up to the main entry point.

Some expect calls are still here to handle Options, and in development there is no backtrace because all errors are ultimately handled and emitted as an error message to the user.

snafu seems really nice fit for this.

It is currently unknown behavior, but repos without a fetch remote should be discoverable.

However, in the checkout command, they should emit a warning and be skipped if they need to be cloned, as gmux would not be able to tell from which remote the repo should be cloned.

We could add a cache system, refreshed when we fetch remote data or change the HEAD ref.

This would speed up multiple calls to git log commands for example.

If the gmux command specifies filters for command outputs, they are only taken into account for standard output, not standard error.

We should use these filters whatever the type of stream we get or log from.

Developed in two days, hopefully tested in two as well.

This will avoid the need to browse the configuration files.

While using gmux pool doiscover, I ended with files in the config that was matching an exclude pattern.

This shouldn't happen.

See clap 3.x tracking issue.

Right now we have yaml and toml files (toml for default settings, yaml for user settings).

Why did we do that, and which one should we pick ?