On Tue, Jan 14, 2020 at 9:56 AM Andreas Schwab <sch...@linux-m68k.org>
wrote:
> On Jan 14 2020, Martin Jambor wrote:
>
> > On Tue, Jan 14 2020, Andreas Schwab wrote:
> >> On Jan 14 2020, Georg-Johann Lay wrote:
> >>
> >>> git clone --reference original-gcc ...
> >>
> >> Don't use --reference. It is too easy to lose work if you don't know
> >> what you are doing.
> >
> > What are the risks, assuming I won't delete the referenced repo which
> > sits on the same partition of the same local disk as the new one?
>
> The risk is if the original repository is gc'd (and nowadays git
> automatically runs git gc --auto from time to time) it may lose objects
> that are still needed by the referencing repository. That doesn't
> happen with git worktree as the main repository knows about all
> references, including worktree local reflogs.
>
Exactly. I used --reference with my local copy of the old git mirror, and
it's hopelessly corrupt now due to needed objects getting gc'd from the
reference repository. Very much not for use by novices without
--dissociate. As the clone man page says,
NOTE: this is a possibly dangerous operation; do not use it
unless
you understand what it does. If you clone your repository using
this option and then delete branches (or use any other Git
command
that makes any existing commit unreferenced) in the source
repository, some objects may become unreferenced (or dangling).
These objects may be removed by normal Git operations (such as
git
commit) which automatically call git gc --auto. (See git-gc(1).)
If
these objects are removed and were referenced by the cloned
repository, then the cloned repository will become corrupt.
I notice that git.html on the website doesn't match what's currently in
wwwdocs git, is automatic updating broken?
Jason
