Duy Nguyen <pclouds@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html