Well, why to store always the full length SHA? I know that looking at the code it is better then asking, but indeed asking is better then guessing and in my case looking at the scary sha low level code is almost like (bad) guessing. We use 40 bytes to disambiguate two unlucky revisions or it is due to UI concerns? In case it is the former does this apply? 40bytes-sha1 + 40bytes-sha2 == 7**bytes-sha1 + 7bytes-sha2 + "a way to disambiguate the two"* (*) as example calculating on the fly the full length sha in the unlikely event it is needed, or storing complete 40bytes sha when needed. (**) 7 is my lucky number ;-) If in the packed tree truncated sha are stored, togheter of course with corresponding revision data, does it is enough to keep the *same* information of a complete pack? For performance reasons, probably the inflating should be done only when necessary, it means all git code should use shrinked sha-s, leaving inflating as a remote and unlikely event. What are the real walls about using small length sha everywhere in git code? Ok. It's enough for collecting a long list of very bad answers. I think I've done my day now! Thanks for your *kind* reply Marco - 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