Or should I be making these "pieces" like `git:(` and `)` configurable through args / env vars?
On the untracked files I personally never leave a file untracked. I either commit it or add it to .gitignore. Though I see how you use git differently, how about a --ignore-untracked to ignore untracked files?
You could try to make more of the prompt configurable but that just seems like more work for yourself. It may be that our goals are just different.
I'm totally on board with you about trying not to leave things untracked. It seems like things always accumulate that shouldn't be committed but are useful; I should probably just move them to a different root folder.
Here's the prompt I use[0], adapted from some shell script I found online somewhere. I'm not going to link to the code because it's kind of ugly but it is up on my github.
A clean repository is subdued but readable blue. When there are unstaged changes there's a red plus, and staged changes get a green plus (some of both is yellow). Any branch discrepancies at all are shown by writing the branch name in bold red.
I don't try to give myself too much information, making the assumption that you'll have to do some digging to get enough detail to actually do anything about the situation.
This is good stuff: I've already added it to my dotfiles git repo that sync between machines I use. I would like, however, an option to turn off the 'git:' bit. Chartjunk is exactly what it is :)
Some don't, but $SHELL is generally accurate enough for Bash and Zsh.
You can also check the shell by checking the PID:
ps -p $$
But then you need to do extra output parsing plus, obviously, ps each time you output $PS1. Which is going to be a little overkill for this project since it's only Zsh and Bash you're wanting to capture and you can always have fallback support for those flags when automatic detection fails.
"But that would take local governments to sign up and developers / designers to begin solving problems that matter to their local society. Might be worth a shot though?"
Tech minds are always want to build a tool, not sure why it's just how we're wired.
Don't.
Just do less and do something.
Ask the "Head of Social Service & Care" you were talking to to get 5 or 10 colleagues to get in a room with yourself and a few other hackers.
Ask them their problems and write it all down. Then build something to solve ONE of their problems. This could be as boring as reducing their wasted time and money by automating a menial task in the departments offices.
Once you've built a thing show them it, then ask them to organise another meeting to talk about other problems. Ask them to invite community members. Then you do it again, and again.
Helping people isn't about building things, it's about talking to them about their problems and solving them. Keyword there "talking".
I love that way of thinking, since you're totally right; everything can't be solved by another tech tool that looks nice on TechCrunch.
I have been lucky enough to be a part of what you're proposing a few times, and it is an amazing (and exhausting!) experience. Talking to them, fully understanding their pain points and even try to go out into "the field" with some social workers is a very important method for solving problems that matter in the right way. I agree. :-)
What I have experienced though, and your mileage may differ, is that even though you want to invite them (and community members) they simply do not have the time unless it's some under-the-radar workshop or some big hackathon. Both good initiatives, but it nags me that there's nothing "in-between".
Our local government is stressed and pushed to its limits, meaning that many initiatives like hackathons and the like needs to yield some sort of return of investment.
Nevertheless, I completely agree with you and thanks for sharing your thoughts!
