Re: Weird shallow-tree conversion state, and branches of shallow trees

On Sat, 14 Apr 2007, Robin H. Johnson wrote:

On Sat, Apr 14, 2007 at 10:56:10AM +0200, Johannes Schindelin wrote:

quoted

Ah! Seems we finally have a user for shallow clones! ;-)

Heh. I'm specifically looking at git, trying to resolve the deficiencies
that were identified during by one of our (Gentoo) SoC2006 projects, on
the potential migration of the Gentoo CVS. Git has matured tremendously
since then.

The primary Gentoo CVS module (gentoo-x86), has 234672 files tracked,
and 1309603 CVS revisions. Between 350k and 500k changesets, depending
on how you merge those revisions.

Couple of the things that were identified either in the SoC project, or
since then.
- Shallow history checkouts are important to our low-bandwidth
 ebuild-tree developers (people in places with 33.6k modems, because
 the phone lines don't work well enough for 56k), or other high latency
 setups.

note that for people on low-bandwideth lines, makeing too shallow a checkout can 
actually end up costing more over time (they will have to pull full revisions 
since they don't have the earlier versions to just pull a diff against)

- Shallow tree (subtree) checkouts, for the developers that focus on
 specific portions of large modules and have no interest in the rest of
 the that tree. Eg. Releng does their work in gentoo/src/releng.

this could either be shallow tree or subproject, depending on how you end up 
orginizing things.

- ACLs specific to subtree commits. Something similar to the cvs_acls.pl
 that FreeBSD uses would be great. Eg gentoo-x86/sec-policy/ is
 restricted to members of the security team (SELinux policies).

since git isn't designed with a single repository, it also doesn't need to worry 
about acl's (in fact, i don't think it has the concept of permissions at all). 
this is up to the people maintaining the 'master' repository to pull from the 
right people

- CVS Keyword-like behavior, to specifically place the path and revision
 of certain files into the file directly, for ease of tracking when the
 file is removed from it's original surrounding. I know this one is
 going to draw some flack, but it's a very common practice for a user
 to copy a file out of the CVS tree, make some modifications, and then
 post the entire changed version up, esp. when the size of the changes
 exceeds the size of diff.

I'm not understanding why you need this. git tracks the file content, not the 
diffs betwen files. a developer does their work and git figures out when you do 
a pull if it's better to send the file or a diff (and if you are sending a diff, 
what you are doing the diff against, it may not be the file that had that name 
before)

there's no need to place the path and revision in the file itself.

David Lang