git conversion in progress

Jason Merrill jason@redhat.com
Tue Jan 14 21:34:00 GMT 2020


On Tue, Jan 14, 2020 at 9:56 AM Andreas Schwab <schwab@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



More information about the Gcc mailing list