Official git export

[K. Macy]

On Tue, Aug 30, 2011 at 4:41 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> On Tue, 30 Aug 2011, K. Macy wrote:
>
>>> My understanding is that with git it's possible to "graft" one tree onto
>>> another, so that most people only have to check out recent history, and
>>> can
>>> check out a separate ancient history.  This has at least been proposed in
>>> the context of the net-im/zephyr upstream, where development happened
>>> concurrently in multiple trees (in different VCSes) for a period of time
>>> maybe ten years ago.  Current development is all consolidated in a single
>>> subversion tree, and the proposal was to convert that repository now to
>>> have
>>> something to work with, and worry about getting the ancient history right
>>> at
>>> a later time.
>>>
>>
>> My knowledge of git is limited but I know that git clone has the
>> --depth option for specifying a shallow clone that only goes back N
>
> I am pretty sure that this results in a repo that is not very useful for
> committing to and pushing from (though I have not really used it, myself, so
> could be mistaken).

Why would that be the case? The gitorious repository only goes back to
7 but is very useful. The amount of history one needs to work is
usually quite limited.

>> changesets. Git also has "submodule" which provides some functionality
>> for the notion of subprojects which can limit what is enclosed within
>> a given repo to some extent.
>
> True, but the word on the street around here is that it's kind of a hack,
> and it doesn't really feel like it would be appropriate for splitting up
> things within base.  (It would, however, make some amount of sense if we
> were ever crazy enough to combine two or more of base, doc/www, and ports.)

Looking at the documentation it is also clear that its applicability
is limited as you imply above. Using gitlinks for managing mixed
repository state is clearly, if not a hackish design. limited in
usability and scope.

Cheers