On Wed, May 09, 2012 at 10:52:56AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Hmm. I was thinking that we supported arbitrary sha1s as note values via > > the command-line interface. But we don't; that is only the internal C > > API, and it is quite difficult to do anything useful with non-blob notes > > via the command-line interface. As you noticed, you can trick it into > > doing so with "-C", but even "-c" has disastrous results (unless you > > like dumping the binary tree object into your editor). > > It is fair to restrict anything that involves an editor or end user > interaction with the terminal output for sanity, and raw tree object data > is on the other side of the border line that defines what is sane, so I > wouldn't have much problem with a new restriction on the command line > interface, except for "-C". Advertising that we store arbitrary binary > out of an existing blob as-is and then starting to refuse taking it sounds > like a non-starter. Fair enough. I was willing to accept the "-C $tree" case as collateral damage under the assumption that nobody is using it. But you're right, the real issue is restricting the "-c" case, as well as the "show" case when reading notes. The right patch would restrict those and leave "-C" alone. -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