Joey Hess

if you want a dir-specific one, you could specify

export ACKRC=./.ackrc.local

as an env variable, and then create that file where-ever you
need to override default behaviour, otherwise it'll use

~/.ackrc

The downside to doing it this way is that you only get one or the other, you can't (afaik) load ~/.ackrc, and then only override certain aspects of it locally. Also, you're constrained to running it from the basedir of your project.
(You might be able to overcome this with a hack based on PROMPT_COMMAND (for bash), or a precmd/preexec function for zsh), which redefines ACKRC appropriately.

Regarding the 'gitability' of it, there's no reason why you can't have a ~/.dotfiles/ackrc, with a symlink to ~
That's how I manage my dotfiles anyway, along with a makefile to create any missing symlinks.

Something like http://kitenet.net/~joey/code/etckeeper/ might work out even better, although I've never really found time to play with it.

The rsync algorithm and program are both great, and I use the program a lot to update directory trees across the network. It's also my default tool for synchronizing two directories on the same system. The rsync program correctly optimizes for this case by skipping the rsync algorithm and completely copying changed files. However, it still uses multiple processes and seemingly still calculates some hashes, making it slower than it needs to be.

Joey found [0] that running rsync once in dry-run mode to find what files have been changed, copying them each with cp, then running rsync a second time to handle things like deletions and file permissions resulted in a major speedup.

[0] http://kitenet.net/~joey/blog/entry/local_rsync_accelerator/

You should take a look at http://vcs-home.branchable.com/ They have a mailing list and a bunch of resources to do similar things.

Right now I use movein[1] to maintain my dot files. Each dotfile is held in it's own repo which is checked out to $HOME via GIT_DIR and GIT_WORK_TREE environment variables. The mr[2] command ties the git repos together as it if was one repo. I use additional repos or branches to handle variations within dotfiles. For work, I try to keep things confined to the relevent directory eg. using local.vimrc[3]

[1] http://stew.vireo.org/movein
[2] http://kitenet.net/~joey/code/mr/
[3] https://github.com/embear/vim-localvimrc

The script itself is transparent. In fact, rvm's site suggests[1] reading it before using it by running the internal curl command in a terminal.

Beyond that, if joeyh is Joey Hess[2], I would be curious to hear how you think Ruby devs and Debian might work better together to fix the current situation (assuming you don't think everything is fine from Debian's point of view and screw the Ruby devs). I'm not trolling or baiting. I am a Debian user myself (since Etch was testing), and as someone who uses Ruby regularly, this whole thing drives me nuts.

[1] http://rvm.beginrescueend.com/rvm/install/

[2] http://kitenet.net/~joey/

NB:
When I said it was written by joey I did not mean to imply anything negative about you or your code.

All I meant was that it was yet another great piece of software written by joey:

* etckeeper (/etc under git)

* git-annex (dark git magic that i am only starting to fully appreciate)

* moreutils (growing collection of the Unix tools that nobody thought to write long ago, when Unix was young)

* tons of trivial debian infrastructure like debian-installer, tasksel, debhelper:)

http://kitenet.net/~joey/code/

I think this behaviour is supposed to be a feature of shell. Pipelines are executed in parallel.

Also, see `sponge` from `moreutils` (http://kitenet.net/~joey/code/moreutils/):

$ man sponge
...
sponge reads standard input and writes it out to the specified file.
Un‐like a shell redirect, sponge soaks up all its input before opening the output file.
This allows constructing pipelines that read from and write to the same file.