Re: git guidance

On 2007.12.07 13:53:11 +0300, Al Boldi wrote:

Ouch... That looks worse than "plain" per-file versioning. Not only do you per definition get "broken" commits if there's a change that affects two dependent files, you also get an insane amount of commits just for testing stuff, or fixing bugs.

And unless you use some kind of union-fs on top (or keep ignored files in special unversioned area in your gitfs, which seems somewhat ugly), you'll probably also have to track lots of files in the working directory that are generated, unless you want to re-generate them after each reboot. And that leads to even more absolutely useless revisions.

Just thinking of my vim .swp files (which I definitely don't want to loose on a crash/power outtage/pkill -9 .<ENTER> dammit) makes me scream because of the gazillion of commits they will produce (and no, I don't want them in some special out of tree directory).

Plus, I have vim setup to _replace_ files on write, so that I can more easily use hard-linked copies with changing all copies at once _unless_ I explicitly want to, meaning that I'd get full remove/add commits, which are absolutely useless. And trying to detect such patterns (rename, then write the changed file with the old name and then delete the renamed file) is probably not worth the trouble, because you coincidently might _want_ to have just these three steps recorded when you happen to perform them manually. And if you go for heuristics, you'll complain each time you get a false-positive/negative.

That said, out of pure curiousness I came up with the attached script which just uses inotifywait to watch a directory and issue git commands on certain events. It is extremely stupid, but seems to work. And at least it hasn't got the drawbacks of a real gitfs regarding the need to have a "separate" non-versioned storage area for the working directory, because it simply uses the existing working directory wherever that might be stored. It doesn't use GIT_DIR/WORK_DIR yet, but hey, should be easy to add...

Feel free to mess with that thing, hey, maybe you even like it and extend it to match your proposed workflow even more. I for sure won't use or even extend it, so you're likely on your own there.

Side-note: Writing that script probably took less time than writing this
email and probably less time than was wasted on this topic. Makes me
want to use today's preferred "Code talks, b...s... walks" statement,
but I'll refrain from that... Just because I lack the credibility to say
that, and the script attached is quite crappy ;-)

Björn

#!/bin/bash
inotifywait -m -r --exclude ^\./\.git/.* -e close_write -e move -e create -e delete . 2>/dev/null |
while read FILE_PATH EVENT FILE_NAME
do
	FILE_NAME="$FILE_PATH$FILE_NAME"
	FILE_NAME=${FILE_NAME#./}

	# git doesn't care about directories
	if [ -d "$FILE_NAME" ]
	then
		continue
	fi

	case "$EVENT" in
		*CLOSE_WRITE*)
		ACTION=change
		;;
		*MOVED_TO*)
		ACTION=create
		;;
		*MODIFY*)
		ACTION=change
		;;
		*DELETE*)
		ACTION=delete
		;;
		*MOVED_FROM*)
		ACTION=delete
		;;
		*CREATE*)
		ACTION=create
		;;
		*)
		continue
		;;
	esac

	case $ACTION in
		create)
		git add "$FILE_NAME"
		git commit -m "$FILE_NAME created"
		;;
		delete)
		git rm --cached "$FILE_NAME"
		git commit -m "$FILE_NAME removed"
		;;
		change)
		git add "$FILE_NAME"
		git commit -m "$FILE_NAME changed"
		;;
	esac
done