Thanks for committing my one-character patch. In the commit message you
said
Come to think of
it, maybe we should disallow symlink inside .git/refs hierarchy;
we update the files there by creat/rename pair, so having
symlinks would not work anyway when you do anything that would
update
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
I would like to know
a use case or two to illustrate why there are symlinks pointing
at real files outside .git/refs/ hierarchy, and how that
arrangement is useful.
I've clearly laid out my case very badly.
Here is the patch via sed
$
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
Matt Draisey [EMAIL PROTECTED] writes:
The behaviour of the symlinked in ref directories has changed from
earlier versions of git. They used to be taken into account in
git-fsck-cache --unreachable.
Can the previous behaviour
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
Matt Draisey [EMAIL PROTECTED] writes:
The behaviour of the symlinked in ref directories has changed from
earlier versions of git. They used to be taken into account in
git-fsck-cache --unreachable.
Can the previous behaviour
The behaviour of the symlinked in ref directories has changed from
earlier versions of git. They used to be taken into account in
git-fsck-cache --unreachable. The code in question would simply stat
the contents of .git/refs and recursively expand any S_ISDIR. Now the
code does an lstat and
5 matches
Mail list logo
