Re: [RFC] Design of name-addressed data portion

From: Petr Baudis <pasky@ucw.cz>
Date: Apr 24, 2005, 20:54 UTC
Message-ID: <20050424205438.GN1507@pasky.ji.cz>
In-Reply-To: <Pine.LNX.4.21.0504241336250.30848-100000@iabervon.org>

Dear diary, on Sun, Apr 24, 2005 at 08:17:23PM CEST, I got a letter where Daniel Barkalow <barkalow@iabervon.org> told me that...

Show 5 quoted lines

> It would be useful to have a bit more structure to the repository, such
> that there are a fixed number of paths that hold all of the information
> about the state of the repository, while the rest of the directory has
> information that is particular to a working directory's state (e.g.,
> index).

Agreed.

Show 6 quoted lines

> 
> 
> I'd propose the following structure:
> 
>  objects/    the content-addressed repository portion
>  references/ the name-addressed repository portion

references/ is just too long for my taste. ;-) What about just refs/ ?

Show 14 quoted lines

>    heads/    the heads that are being used out of this repository
>      DEFAULT the head that people pulling this repository mean by default
>      ...     other heads, by name, that fsck-cache should mark reachable
>    tags/     the tags
>      ...     files with the symbolic name of the tags, containing the hash
>  info/       other per-repository information
>    remotes   URLs of remote repositories
>    complete  hashes that the repository contains all references from
>    missing   hashes that the repository lacks but wants
>    excluded  hashes that the repository doesn't want
>  ...         other files are per .git directory, not shared on push/pull
>  index       
>  HEAD        symlink to the head that is the local default
>  tracked     remote that this working directory tracks

I will probably throw the local stuff to local/.

I think I like this otherwise.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor