Possibility of coloring files based on git status?

[spenserblack]

Still learning about this tool and its features, but I just wanted to get the idea out there. Apologies if there's already a feature for this.

I spend more time in directories that are repositories than aren't, and I call git status very frequently to ensure that the desired changes are staged. I'm thinking that color coding, or adding some sort of special character, would be very helpful for my workflow. A color for a file with staged changes, unstaged changes, a new unstaged file, a new staged file, etc.

You can get a format that can be easily parsed with git status -z --porcelain, which will return a list of staged and unstaged file statuses separated by NULL characters ("\0").

[leo-arch]

For the time being clifm provides only external git-integration (see the git-integration section). What this plugin does is pretty simple: it runs a git command (which can be customized to your liking by just editing the script) with each new prompt, so that you can keep track of your git repos.

To perform file colorization (and other stuff) based on the git status we need full, internal integration via the libgit2 C library and new code added to our files listing routines. Doable? Totally, but it implies a new dependency and more computation for each listed file (which of course results in slower listing times). However, this feature has been in my TODO list for quite a while: it's definitely not a bad idea.

[spenserblack]

🤔 When onefetch switched out calls to subprocesses to using libgit2, we actually found a degredation in performance IIRC. (I think o2sh/onefetch#341 was the PR?)

I used to avoid calls to subprocceses like the plague, but for git I'm changing my mind and finding it reasonable to use subprocesses. I know very little about how C projects are organized, so here's a rough Golang example (for readability, hopefully 🙂) to write something that's testable.

type Git interface {
	Callable() bool
	Call(args ...string) (stdout string, stderr string, exitCode int)
}

type NoGit struct{}

func (NoGit) Call(args ...string) (stdout string, stderr string, exitCode int) { return }
func (NoGit) Callable() bool                                                   { return false }

type GitCommand struct{}

func (git GitCommand) Call(args ...string) (stdout string, stderr string, exitCode int) {
	// call command
	return "output", "error", 0
}
func (GitCommand) Callable() bool { return true }

type MockGit struct{}

func (git MockGit) Call(args ...string) (stdout string, stderr string, exitCode int) {
	// return mocked responses based on args
	return
}
func (MockGit) Callable() bool { return true }

func colorize(file string, git Git) {
	// pass MockGit for testing
	if git.Callable() {
		stdout, stderr, exitCode := git.Call("status", "--porcelain", "-z")
		// handle values to colorize
	}
	// default behavior
}

[leo-arch]

So, this code is just running git(1), isn't it? This is basically what git_status.sh does at every new prompt. Have you tried it? For me, it works pretty well, but it all depends on your needs.

[spenserblack]

🤔 A bit different than what I was thinking, but you're right that it accomplishes the same basic thing.