Hi, On Mon, 13 Oct 2008, Shawn O. Pearce wrote: > Stephan Beyer <s-beyer@xxxxxxx> wrote: > > Johannes Schindelin wrote: > > > and I would have expected others to need a lot less arguments > > > to see it that way, too. > > > > Despite the fact that I've never used hardlinks in a git repository, I > > would have expected git to keep them. So I'm one of the "others" who > > thinks this config option is just sane (and should perhaps even be > > enabled by default, if it does not break stuff on file systems that do > > not have a hardlink feature... but ok) > > My problem is many users do "cp -rl a b" to clone a->b and hardlink the > working directory. They expect "cd b && git checkout foo" to then only > unlink the paths that differ. Updating the original inode would break > repository a. > > Its a change in behavior, to some of our oldest users. So it can't > really be on by default. Which is the reason why my commit is not titled "Make Git respect hard links by default", but "Introduce core.keepHardLinks". I also hate people who try to break my setup. Which scenario (breaking someone's setup) was exactly what triggered this patch. Ciao, Dscho -- 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
