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
Matt Draisey <[EMAIL PROTECTED]> writes:
> Having thus been forced to read the mailing list, I see a slight problem
> in .git/objects/info/alternates mechanism. Using the original
> ALTERNATE_DB_ENVIRONMENT variable you assert to the git programmes that
> you know all the repositories to search f
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
Matt Draisey <[EMAIL PROTECTED]> writes:
> 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.
>...
> This email is
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 projects do benefit from having their ow
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 previou
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 previou
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 be reinstated?
I would not have much problem accepting a p
On Mon, 15 Aug 2005, Matt Draisey wrote:
>
> The behaviour of the symlinked in ref directories has changed from
> earlier versions of git.
Hmm.. There used to be a mix of lstat() (in receive-pack) and stat() (in
fsck-cache.c, and it got standardized in one function which used lstat.
The reason
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
10 matches
Mail list logo
