Linus Torvalds [off-list ref] writes:
(Which admittedly is a bit odd. The reason I didn't ever seriously even
consider monotone was that the initial import was so *incredibly* sucky,
and took hours for the kernel. So use "-l" for benchmarks, and damn my
"I hate hardlinking repos" idiocy).
I would call aversion to -l a superstition, while aversion to -s
has a sound technical reasons. The latter means you need to know
what you are doing --- namely, you are making the clone still
dependent on the original.
Junio C Hamano [off-list ref] writes:
Linus Torvalds [off-list ref] writes:
quoted
(Which admittedly is a bit odd. The reason I didn't ever seriously even
consider monotone was that the initial import was so *incredibly* sucky,
and took hours for the kernel. So use "-l" for benchmarks, and damn my
"I hate hardlinking repos" idiocy).
I would call aversion to -l a superstition, while aversion to -s
has a sound technical reasons. The latter means you need to know
what you are doing --- namely, you are making the clone still
dependent on the original.
Well, I'd not call the -l aversy a complete superstition: it means
that cloning a repository won't provide any redundancy worth noting
against file system corruption.
--
David Kastrup
On Tue, Jul 31, 2007 at 10:50:48PM -0700, Junio C Hamano wrote:
I would call aversion to -l a superstition, while aversion to -s
has a sound technical reasons. The latter means you need to know
what you are doing --- namely, you are making the clone still
dependent on the original.
So would you accept a patch which adds a git-config variable which
specifies whether or not local clones should use hard links by default
(defaulting to yes), and which adds a --no-hard-links option to
git-clone to override the config option?
I could imagine a situation where if you are using a git repository
exclusively on a local system, with no remote repositories to act as
backups, where you might want git clone to to make full copies to
provide backups in case of filesystem or disk induced corruption. But
most of the time there are enough copies of the the repo on other
machines that the need for making separate copies of the git
objects/packs isn't really needed.
- Ted