Re: Switching from old git tree

[Ken Raeburn <raeburn@raeburn.org>]

On Nov 15, 2014, at 04:18, David Kastrup <dak@gnu.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: Kenneth Raeburn <raeburn@raeburn.org>
>>> Date: Sat, 15 Nov 2014 03:43:05 -0500
>>> 
>>> After creating your "main" clone of the new upstream repository,
>>> clone *that* one locally (use the "-s" option to save disk space)
>> 
>> Careful: kids are listening!  The -s option to clone has a caveat on
>> its man page, which, to me sounds as "Kids, don't try this at home!"
> 
> -s does not save disk space over the default _unless_ your local clone
> happens to be on a different file system.  There is little reason to
> keep local clones on different file systems, however.  On the same file
> system, the normal git clone operation uses hard links, and those are
> unproblematic regarding the given caveat.

I'd forgotten that hard links were the default, I was thinking it would copy the needed objects. Even so, the disk space usage would have only been temporary, for the life of the repository used for merging. Yes, leaving out -s is probably the right thing in most cases.

But the general idea of using a second, temporary repository for the merging, and pushing only the updated branches back to the main repository, will save space in the long run, and without needing the 30-day delay, GC, etc. It also lets one start practicing pulling and pushing changes between repositories.

Ken