Junio C Hamano wrote: > Liu Yubao <yubao.liu@xxxxxxxxx> writes: > > > A hint for understanding why loose objects are compressed is that > packfiles were invented much later in the history of git. > > These are both good questions, and it might have made a difference if they > were posed in early April 2005. > > At this point, the plain and clear answer to both of these "Why not" > questions is "because that is the way it is and it is costly to change > them now in thousands of repositories people use every day." > > In other words, it is not interesting anymore to raise these questions > now, especially as a suggestion to change the system, unless they are > accompanied by arguments that convinces everybody that the cost of such a > change outweighs the benefits, and a clear transition plans how to upgrade > everybody's existing repositories without any pain. > Thanks for your explanation, but I doubt if it's too costly to change the format of loose object, after all this doesn't change the format of pack file and affect git-pull/fetch of old git client. I ask the "why not" questions because I doubt if I miss some technical points that the change isn't worth at all in fact. If no severe technical problem will occur, I think it's worth breaking *forward* compatibility for better performance and I'm willing to implement it. Some cons and pros. cons: * old git client can't read loose objects in new format (People degrade git rarely and old git can read pack files generated by new git, so it's not a big problem) pros: * avoid compressing and uncompressing loose objects that are likely frequently used when you are coding/merging * share loose objects among multipe git processes * the new code path is simpler although we will have more code paths for compatibility Best regards, Liu Yubao -- 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
