I wrote:
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

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

Reply via email to