Re: [PATCH] Introduce core.keepHardLinks
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Oct 13, 2008, 17:55 UTC
- Message-ID
- <alpine.DEB.1.00.0810131954180.22125@pacific.mpi-cbg.de.mpi-cbg.de>
- In-Reply-To
- <20081013162351.GQ4856@spearce.org>
Hi,
On Mon, 13 Oct 2008, Shawn O. Pearce wrote:
Show 18 quoted lines
> 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