It's a trade-off, I know.
Paul Jackson replied:
So where do you recommend we make that trade-off?
Daniel Barkalow wrote:
So why do we have to be consistant? It seems like we need a standard format for these reasons:
- We use rsync to interact with remote repositories, and rsync won't understand if they aren't organized the same way. But I'm working on having everything go through git-specific code, which could understand different layouts.
- Everything that shares a local repository needs to understand the format of that repository. But the filesystem constraints on the local repository will be the same regardless of who is looking, so they'd all expect the same format anyway.
So my idea is, once we're using git-smart transfer code (which can verify
objects, etc.), add support for different implementations of sha1_file_name suitable for different filesystems, and vary based either
on a compile-time option or on a setting stored in the objects
directory.
I think that's the perfect answer: make it a setting stored in the objects directory (presumably set during initialization of the directory), and handled automagically by the tools. I recommend handling them NOT be a compile-time option, so that the same set of tools works everywhere automatically (who wants to recompile tools just to work on a different file layout?).
The only thing that matters is that repositories on non-special web servers have a standard format, because they'll be serving objects by URL, not by sha1.
If the "layout info" is stored in a standard location for a given repository, then the rest doesn't matter. The library would just download that, then know how to find the rest.
--- David A. Wheeler - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
