All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Alexander Gladysh <agladysh@gmail.com>
Cc: Kjetil Barvik <barvik@broadpark.no>, git@vger.kernel.org
Subject: Re: Troubles when directory is replaced by symlink
Date: Thu, 11 Jun 2009 07:48:46 -0400	[thread overview]
Message-ID: <20090611114846.GC4409@coredump.intra.peff.net> (raw)
In-Reply-To: <c6c947f60906090118n78d3c40fq11d1390f8776c2c0@mail.gmail.com>

[Kjetil: I bisected this bug to your 92604b4. Details below.]

On Tue, Jun 09, 2009 at 12:18:16PM +0400, Alexander Gladysh wrote:

> Any help here? This bug is pretty annoying (especially that it
> requires double hard resets).
> 
> Should I provide any extra information?

Actually, I think the problem happens earlier than you realize; I see
problems when switching back to master:

-- >8 --
# make a repo
mkdir repo && cd repo && git init

# content in alpha
mkdir alpha && echo content >alpha/file && git add . && git commit -m one
# and duplicate content inside beta
mkdir beta && cp -R alpha beta && git add . && git commit -m two

# now replace the duplicate with a symlink
git checkout -b branch
rm -rf beta/alpha && git add -u && git commit -m deleted
ln -s ../alpha beta/alpha && git add . && git commit -m symlink

# now checkout master again; alpha/file will be missing, even
# though it wasn't touched at all
git checkout master
git status
-- 8< --

We handled this correctly in v1.6.1, so I was able to bisect it down to:

    commit 92604b466344b2157efc42ef3521dac22d7906a2
    Author: Kjetil Barvik <barvik@broadpark.no>
    Date:   Sun Jan 18 16:14:50 2009 +0100

        lstat_cache(): more cache effective symlink/directory detection

        Make the cache functionality more effective.  Previously when
        A/B/C/D was in the cache and A/B/C/E/file.c was called for,
        there was no match at all from the cache.  Now we use the fact
        that the paths "A", "A/B" and "A/B/C" are already tested, and we
        only need to do an lstat() call on "A/B/C/E".

I don't have time to look more closely now, but I'm guessing we are
treating the symlink to the directory like the directory itself in a
place that we shouldn't.

-Peff

  reply	other threads:[~2009-06-11 11:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-05  5:43 Troubles when directory is replaced by symlink Alexander Gladysh
2009-06-09  8:18 ` Alexander Gladysh
2009-06-11 11:48   ` Jeff King [this message]
2009-06-11 14:37     ` Kjetil Barvik
2009-06-14 14:34     ` Kjetil Barvik
2009-06-24 22:07       ` James Pickens
2009-06-25 22:51         ` Kjetil Barvik
2009-06-26 13:14         ` Kjetil Barvik
2009-06-26 14:14           ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090611114846.GC4409@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=agladysh@gmail.com \
    --cc=barvik@broadpark.no \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.