On Wed, 22 Aug 2007, Josh England wrote: > > The main need is for file ownership/permission, which has been touched > on before. When I clone an image, I really want an *identical* clone, > in every way. It seems as though git had this functionality but > scrapped it due to issues with umask and merge type problems? Well, git had all permission bits, but never ownership. And yes, using more than the one user-x-bit ended up being totally unusable for source code, because of different people having different umask, so we effectively dropped the permission bits too (although the data format was retained, so we could re-introduce then with some flag that says "honor all permission bits, not just the x bit"). But the ownership thing we've never even tried to support, since it was so obviously not something that was appropriate for a distributed project. So if you want an identical clone with ownership and (full) permissions, you really do need to have some alternate way to fill in the blanks. I've argued that ".gitattributes" may be an acceptable alternate, especially since ownership is often something that is less than "per file", and more often "has certain patterns". > So the question is: would there be any way to bring this functionality > back as a non-default configurable option? For those of us who need the > functionality, we'd be more than willing to live with some of the > side-effects. Full permissions might be easy enough to resurrect, but since it's still pointless without ownership, that really isn't even relevant. But if .gitattributes would work, you probably could introduce both full permissions and ownership rules there. We read git attributes for *other* reasons when checking files out _anyway_, ie we need the CRLF attribute stuff, so adding ownership attributes would not be at all odd. Linus - 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
