On Sat, Apr 25, 2015 at 01:00:58AM -0400, Jeff King wrote: > A better solution to what I proposed earlier is perhaps: > > git config alias.debug '!gdb --quiet \ > -ex "break exit" \ > -ex "run" \ > -ex "bt full" \ > -ex "continue" \ > -ex "quit" \ > --args git \ > ' > git debug rev-parse foobar > > It has the minor irritation that gdb will control the process stdio > (slurping from stdin and polluting stdout, whereas we would prefer no > input and output to stderr). There might be a way to convince gdb to do > otherwise, or you could probably go pretty far with some shell fd > redirects and using "set args" inside gdb. Or maybe something with > gdbserver. Just to extend the thought exercise, here is something marginally less horrible. Save as "git-debug" in your PATH and chmod +x. -- >8 -- #!/bin/sh if ! type gdb >/dev/null 2>&1; then echo >&2 "Sorry, you don't seem to have gdb installed." exit 1 fi args= for i in "$@"; do args="$args '$(printf '%s' "$i" | sed "s/'/'\\\\''/")'" done gdb --quiet \ -ex "set args $args <&7 >&8 2>&9" 7<&0 8>&1 9>&2 </dev/null >&2 \ -ex 'break exit' \ -ex 'run' \ -ex 'bt full' \ -ex 'continue' \ -ex 'quit' \ git -- 8< -- It's still rather hard to use with sub-programs started by git (e.g., the upload-pack spawned by a fetch), but I think it would work for many simple cases. I'm not sure if I would use it myself. As somebody confident in using gdb, my next step after seeing the backtrace would be to start poking around interactively. Besides the stdio magic, this is not really buying me much beyond running gdb myself. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html