Re: [PATCH v2 0/1] git-clone: fix relative path problem in the alternates

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 22, 2011, 21:57 UTC
Message-ID: <7vliulun2a.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vzkj1uqpa.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> While at it, we may probably want to update the command option handling so
> that you can give more than one --reference= parameters.

Geez. There appear to be more bugs in the existing code.

If you

 - specify --reference;
 - the source of the clone is a local directory;
 - you do not specify --shared; and
 - the source of the clone has its own alternates

we end up exercising this call flow:

	init_db();
        setup_reference();
        -> add_to_alternates_file();
           This writes objects/info/alternates in the new repository
	clone_local();
        -> copy_or_link_directory(src/objects, dst/objects);
           -> copy_or_link_directory(src/objects/info, dst/objects/info);
              -> unlink(dst/objects/info/alternates);
                 link(src/objects/info/alternates, dst/objects/info/alternates);

and lose the --reference given from the command line.

The problem you are trying to address is a valid one, but it needs to be fixed by teaching copy-or-link-directory that objects/info/alternates is special. We need a more proper fix than "just let the recursive copy do a possibly wrong thing and then patch it up if it is wrong", which is the approach taken by your patch.