> Interesting. Debugging one's alias entries would be helped with > this I would imagine, and for that you would want something like > this: > > > Example: > > % git showtag v1.4.1-rc1 > /dev/null > > trace: exec: /home/matled/local/stow/git/bin/git-showtag v1.4.1-rc1 > > trace: exec failed: No such file or directory > * trace: expanded alias "showtag" => "cat-file tag" That's a good idea, I'll integrate that. > By the way "git cat-file -p" or "git verify-tag -v" might be > more pleasant to view a tag since they make the tagger timestamp > human readable. Ok, yesterday I was searching for something to see the annotation of a tag. verify-tag -v looks quite much like that, is there any other way to read this? Or in general: how do I work with tags? I want to build a version tagged as v1.2 so currently I'll do > git checkout -b 1.2 v1.2 and built it. But then I've to type the version number twice (typing it once is annoying enough :)) and I've to type it once more to get the tag annotation. > Might be worth reusing quote.c::sq_quote(), perhaps? Oh, sure, did not know about this. This would result in a loop of malloc'ing memory for the buffer. Is this ok? Or should I add a function like sq_quote which takes a stream and writes to it? So for the --trace part I think an environment variable GIT_TRACE is more suitable for this because children inherit this. So running git status will show what internal commands the shell script uses. Otherwise I see no way to pass the --trace option down because an extern program like git-status, git-annotate etc will not accept parameters which can be passed to `git'. - : 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