On Sat, 16 Apr 2005, Paul Jackson wrote:
> David wrote:
> > It's a trade-off, I know.
>
> So where do you recommend we make that trade-off?
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. 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.
-Daniel
*This .sig left intentionally blank*
-
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
