Shawn O. Pearce wrote: > 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. > Yes, exceptional case, is it acceptable that core.uncompressedLooseObject is set to false by default especially for NFS file system? >> 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. > I mean to add a format, not to replace the current format of loose object. >> 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. > In my company we have a central server to host source code repository managed by git+ssh. Some collegues also work on the same machine (maybe not a good practice) and set alternates to the central repository, so there can be multiple git processes operating same git object database. In fact we have a wrapper script of git to make git fit our development process better because git's submodule support isn't good enough. One command in the wrapper script can execute many git commands in a short time. >> * 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. > Could you review my patches sent just a moment ago? The key changes are rather small. 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
