Re: Multiple checkout copies

[Achim Gratz]

Richard Stallman writes:
>    > $ git clone --shared emacs-1 emacs-2
>
> sounded like just the right thing until you posted
> the caveat.  After this, I hesitate to use it:
>
>         > Using --shared may be risky, as Git may choose to GC the
>         > dangling objects away from emacs-1, not taking into account the
>         > possibility of them being used in some other trees.  In my case,
>         > the source directory is often a “bare” Git repository used only
>         > to mirror the upstream one, and thus it has no “local” commits,
>         > which are somewhat likely to become dangling after rebases and
>         > such.

That's mostly a red herring.  The objects shared are hard-linked, so
even if the GC removes objects in a repository that doesn't reference
them anymore they continue to exist in the repository that still needs
them.  As long as you do not delete that other repository you cannot
lose anything.

> Maybe I could use it in that way, but is there no way to make two
> working trees both checked out in parallel from the same repository?

The officially sanctioned Git way of getting a new worktree is to make
another clone.  If you don't intend to use it as a full repository later
on, you can do a shallow clone or you can use another repository as an
"alternate" to skip copying / linking the object files.

There is a sort-of way of splitting off additional working trees, either
using the --work-tree argument or by setting the GIT_WORK_TREE
environment variable or even manipulating the core.worktree property of
the repository.  But you can only ever make changes on a single worktree
anyway since a lot of meta-information regarding the worktree is also
kept in the repository, so while you have those multiple working
directories, only the last of them is properly "checked out".

The way to do this properly is to link all shared information back to
the original repository (I'd only ever use a bare one for this) and keep
the per-worktree files separated.  The git-new-workdir script does this,
but it's still in contrib since it doesn't work on some systems.

http://git.kernel.org/cgit/git/git.git/tree/contrib/workdir/git-new-workdir

You are quite likely on a system where that script works, so it would
just be a matter of dropping it into /usr/lib/git and making it
executable.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada