What about using the new git-config crate for a gix config subcommand?

[Byron]

Even though I would like to keep it short, I hope I can get the conversation started. As gix wants to be improve usability on common git workflows, I was thinking what could be done with the newly gained capabilities in git-config to provide some value for the common CLI user.

Reading git configuration

Currently, when executing git config, you will get…

git config
usage: git config [<options>]

Config file location
    --global              use global config file
    --system              use system config file
    --local               use repository config file
    --worktree            use per-worktree config file
    -f, --file <file>     use given config file
    --blob <blob-id>      read config from given blob object
[…much much more…]

…and I usually find that overwhelming. For some reason I can't remember that -l lists all git config values, and it does that in a way that doesn't look particularly friendly either:

git config -l
credential.helper=osxkeychain
push.default=simple
diff.tool=/Applications/Xcode.app/Contents/Applications/FileMerge.app/Contents/MacOS/FileMerge
alias.co=checkout
[…a long long list of lines which won't bother adding some whitespace for readability…]

What could be done provide value in the moment someone runs gix config by itself? My intuition is to list all values like so:

$ gix config

[credential]
  helper = osxkeychain
  something-else = value
[push]
  default = simple
[... and much much more structured input …]

For now this would just be values from the repository's config file, but in future it could be the merged result of all available git config files.

What if we provide some keynames as well?

$ gix config remote branch
[remote "origin"]
   url = https://github.com/Byron/gitoxide
[remote "rad"]
   url = ad://hynkuwzskprmswzeo4qdtku7grdrs4ffj3g9tjdxomgmjzhtzpqf81@hwd1yregyf1dudqwkx85x5ps3qsrqw3ihxpx3ieopq6ukuuq597p6m8161c.git
[branch "main]
  remote = origin

Or with globs?

$ gix config 'remote.or*'
[remote "origin"]
   url = https://github.com/Byron/gitoxide

From there it's certainly possible to figure out a way to edit values comfortably and intuitively, but I leave that conversation for another day.

What's your thoughts on this one?

CC: @edward-shen

[edward-shen]

I think it's definitely a good idea, especially since it's effectively just a frontend for git-config. That being said, I think the existing output that git does is useful for scripting, so if anything I'd like to have a backwards compatible version where the output is easier for scripts for parsing.

In terms of priority, I feel like this would be lower end (read: after we get cloning working).

[Byron]

That being said, I think the existing output that git does is useful for scripting, so if anything I'd like to have a backwards compatible version where the output is easier for scripts for parsing.

That's true, and gix doesn't necessarily cater to as for that there is gitp (for plumbing) or the original git. Thus the backward compatibility is nothing I would be concerned about at all as gix is not a replacement for git, but can be a user-friendly alternative for common workflows. When thinking about scripting, I also would leave that field to git as ideally, gitoxide's APIs is easy enough to get started with and write tools in the form of Rust programs.

In terms of priority, I feel like this would be lower end (read: after we get cloning working).

Definitely, even though I usually like to stroll sideways and extract something usable from early crates so people can start using gitoxide early (or earlier).

All that said, it's all about how to have the most fun as well so having more options on the table will hopefully help with that.

As a side-note, I have opened an entirely new line of work focussed on allowing to push (and generate packs) which is mostly on my plate and is sponsored by @joshtriplett. There is also radicle.xyz who think about providing a grant to gitoxide, and I hope they will open a discussion about this here when they are ready. This would provide some general funding to shed out to contributors in some shape or form that is still to be determined. You might want to join the waitlist on the GitHub Sponsor program if that interests you, they are not exactly fast at least in my case 🤦‍♂️.

[Byron]

I am happy to announce that a first version of gix config is now available in the latest release. It works like described here and has a few neat details that make it even more useful.