Liu Yubao <yubao.liu@xxxxxxxxx> wrote: > 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. It is too costly; Jakub pointed out the dumb protocol clients would have issues with the new format. Anyone copying a repository between machines using scp or a USB memory stick may also run into a problem. Etc. > 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) That's a pretty big con. We can also add slower performance on NFS, as has been reported already by others. > pros: > > * avoid compressing and uncompressing loose objects that are likely > frequently used when you are coding/merging True, loose objects are among the more frequently accessed items. > * share loose objects among multipe git processes Probably not a huge issue. How many concurrent git processes are you running on the same object store at once? During development? Its probably not more than 1. So sharing the objects doesn't make a very compelling argument. > * the new code path is simpler although we will have more code paths for > compatibility The new code path is more complex, because although one branch is very simple (mmap and use) the other code paths have to stay for backwards compatibility. Every time you add a branch point the code gets more complex. It works well enough now, and is at least one branch point simpler than what you are proposing. So I'm not really interested in seeing the change made. -- Shawn. -- 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
