On Mon, Apr 04, 2016 at 02:24:48PM -0400, Santiago Torres wrote: > > I think it can be part of this series, but doesn't have to be. As I > > understand it, the current code is just handing the name to the `git > > verify-tag` process, so if we continue to do so, that would be OK. > > IIRC, the current code for git tag -v hands the hex-representation[1] of > the sha1 to git verify-tag --- I believe that's related to the > desamgibuation issue I've seen people discuss. I think this behavior is > lost unless we add this on top of the patch. Oh, you're right. I didn't notice that. So yeah, we should make sure in this series to hand the sha1 over to gpg_verify_tag(). > > Yes, though I'd generally advise against a function taking either a name or > > a sha1, and ignoring the other option. That often leads to confusing > > interfaces for the callers. Instead, perhaps just take the sha1, and let > > the caller do the get_sha1() themselves. Or possibly provide two > > functions, one of which is a convenience to translate the name to sha1 > > and then call the other. > > I think the former sounds easier. I can replace the name argument and > move the sha1-resolution code to in verify-tag. git tag -v already > resolves the tagname to a sha1, so it is easier there. > > Does this sound reasonable? Yes, I think that is a good solution. Thanks. -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