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

From: David Lang <david.lang@digitalinsight.com>
Date: Apr 15, 2007, 00:02 UTC
Message-ID: <Pine.LNX.4.63.0704141655390.31807@qynat.qvtvafvgr.pbz>
In-Reply-To: <20070415000330.GG3778@curie-int.orbis-terrarum.net>

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

Show 17 quoted lines

> On Sat, Apr 14, 2007 at 10:56:10AM +0200, Johannes Schindelin wrote:
>> 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

Show 7 quoted lines

> - 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