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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
