Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > On Wed, May 23, 2012 at 9:09 PM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote: >> >> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> >> --- >> makes sense to me, but I might have overlooked something > > while it's still making sense for me, i think it's more logical to > move the check to the caller, where "entry in pack?" check is also > done. I think most of the callers of sha1_object_info_extended() are using this function, saying "We expect this object to exist somewhere, perhaps in pack or perhaps in a loose form, and trying to see what it is", and they rely on the first error message "unable to find" to be issued. So in that sense, I do not see how this patch makes any sense at all. Care to point out a codepath where we throw a random 20 bytes at it in order to see if an object with the given object name exists? That would be the only case where "unable to find" might be an unwanted error message. -- 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