Joey Hess

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/

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/

Here's my announcement post, which is, I hope, worth reading for some context of what's going on in 1981 "now": http://kitenet.net/~joey/blog/entry/announcing_olduse.net/ Also, if you see a blank box where the newsreader should be, yeah, inviting the whole web in to run tin on my server is not a completely scalable thing. nntp.olduse.net is where it's at.

This reminds me of Debian's pristine-tar: https://kitenet.net/~joey/code/pristine-tar/ https://joeyh.name/blog/entry/generating_pristine_tarballs_from_git_re…

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.

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

I think this does the same as mr (http://kitenet.net/~joey/code/mr/), though mr supports repository formats than just git at the moment.

git-annex http://kitenet.net/~joey/blog/entry/databranches/ "databranches: using git as a database" http://git-annex.branchable.com/ "git-annex is a git subcommand that allows tracking large files in git -- without the bother of feeding their contents into the git repository!"

Joey Hess just blogged[0] about ShareBox[1] which creates a fuse filesystem built on git-annex. I don't know either well enough to comment on them. [0] http://kitenet.net/~joey/blog/entry/new_git-annex_use_cases/ [1] https://github.com/chmduquesne/sharebox

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/

the autopackage site has no (easily) locatable links that compare it with new installation systems like 0-install, Nix. Can you comment on what advantages does autopackage have over other package managers. Correct me if I'm wrong, but all package managers are essentially cross distro - I can run rpm/yum on my Ubuntu machine. And a google search turns up .... umm.. this - http://kitenet.net/~joey/blog/entry/autopackage_designed_by_monkeys/

I think it was Joey Hess: - http://kitenet.net/~joey/cvshome/ (CVS) - http://onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html (SVN)

Take a look at the mr command. I find it very handy for working with heterogeneous collections. http://kitenet.net/~joey/code/mr/

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.