Re: how to make "full" copy of a repo

[Junio C Hamano <gitster@pobox.com>]

Duy Nguyen <pclouds@gmail.com> writes:

> This is true. But I wonder if we should (and can) support
> --super-mirror option (disabled by default), where reflog and stashes
> are kept, for backup purposes. We might keep unreferenced objects as
> well if it's not hard to do.

I doubt that we want to be in the business of filesystem backup.  Is
there a practical use case that is *not* "I am relocating out of
this directory on this machine and will be using the other one I am
making by copying"?

For the "I am relocating" scenario, rsync is the most suitable
option.  The caveat "activity at the original will leave the copied
result incomplete" will apply to whatever transport method you use,
but in the "I am relocating" scenario, you will have a period that
the original is quiet (i.e. you stop using the original at some
point before you start the copied one, and do not expect that the
sequence to take zero down time).

In a sense, "super-mirror" is even worse, if it is doing some "Git
activity" on the source which we may want to log, which means the
original will never be quiet during the copying.  Sure, send-pack
may not currently not do any logging in the original repository, but
depending on the reason why such a copy is being made, the original
may even have a custom hook-based logging data left somewhere in the
repository and for copying such a repository the repository owner
would want to keep the logged data.

And if what super-mirror does is not considered a "Git activity" and
somehow bypasses all the Git rules in the original repository, then
what is the advantage of having it in Git in the first place, over
using something like rsync?