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 effe
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
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
On Mon, 2005-08-15 at 00:41 -0700, Junio C Hamano wrote:
> Matt Draisey <[EMAIL PROTECTED]> writes:
>
> > ... My own programming efforts rarely exceed two or three files
> > per project, and don't justify there own .git/objects repository.
> > Still, a few pr
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
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
6 matches
Mail list logo
