From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Fri, 08 Jun 2007 18:35:58 GMT
Subject: Re: clarify git clone --local --shared --reference
Message-ID: <4669A18E.4080702@nrlssc.navy.mil>
In-Reply-To: <AF0367BA48C55940A43CCF08DF35553C013C76BF@az33exm24.fsl.freescale.net>

Loeliger Jon-LOELIGER wrote:
> Shawn O. Pearce wrote:
>> Brandon Casey <casey@nrlssc.navy.mil> wrote:
>>> ok. I just want to make sure this is not really about prune'ing.
>>>
>>> In the following, source and --shared repos are identical except...
>>> 1) Source repo contains loose objects which are new commits.
>>>    --shared repo does git-pull.
>>>    we fast-forward, copying very little.
>>>    success.
>> Copying nothing actually.  All of the objects required are in the
>> source repository, so --shared needs nothing additional.
> 
> So the thing I find myself wanting to do is
> A "crib from local copy".  That is, the network
> Cost is large, so when cloning point to a local
> (ie, already on same Filesystem) clone that is
> Similar, use it as a reference, but, in the end,
> Create a complete copy into the new repository.
> 
> I don't want it hard linked with --local.
> I don't want it shared with --shared.
> I don't want it as an altrnate source with --reference.
> 
> What I want is a new, clean, complete, unshared repository.
> 
> But for efficiency reasons, I want to grab objects
> From a different, filesystem-local clone if possible.
> 
> Does that work?

I don't think that exact behavior is implemented yet, but...

If the filesystem-local repo is pure subset version of the source repo 
you could do this:

(assuming the filesystem-local repo is on branch master, and that is 
what you want)
git clone -l <filesystem-local repo> <my_new_repo>
cd <my_new_repo>
git pull <source-repo>

No reason not to use -l on clone in this case IMO.

Otherwise...
If the filesystem-local repo has changes past the master HEAD on source 
repo that you are not necessarily interested in...

1) git clone -l -n <filesystem-local repo> <my_new_repo>
2) cd <my_new_repo>
3) git fetch <source_repo> master:tmp
4) git branch -M tmp master
5) git checkout master

1) Here we use -l to encourage hard linking (no reason not to IMO),
    and tell clone not (-n) to checkout the active branch.
3) Now fetch the master branch from the source_repo and store into
    a new branch named tmp.
4) Rename tmp to master.
5) Checkout the files.
- Now the HEAD of master branch is at the same commit as the
   source_repo.

One drawback is that origin is now tracking the filesystem-local repo, 
so a git pull without supplying a repo will pull from filesystem-local repo.

-brandon