Hi,

On Mon, 13 Oct 2008, Shawn O. Pearce wrote:

quoted text
> Stephan Beyer <s-beyer@gmx.net> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html