Peter Baumann <waste.manager@xxxxxx> writes: > git-new-workdir creates a new working directory where everything > necessary, including .git/packed-refs, is symlinked to your master repo. > But git-pack-refs breaks the symlink, so you could accidentally loose some > refs. > > This fixes git-pack-refs to first dereference .git/packed-refs if it is a > symlink. While we are it, add some tests to prevent this from happening > again. Because you are only fixing the case where the worktree is borrowing the packed-refs file from a real repository with a symlink trick, and we do not know if somebody had his packed-refs as a symlink to some random place for reasons other than creating a lightweight worktree (maybe there was a mistake), I am wondering if it makes sense to be more strict about the value we read from readlink(). For example, if it does not end with "/packed-refs", doesn't it suggest that the reason because the symlink is there is different from the case you are handling (i.e. it is not a packed-refs symlink in a lightweight worktree that points at the corresponding real repository)? I wonder if in such a case we would want to signal an error, instead of overwriting whatever real file the symlink points at. Or is it too strict and paranoid? I dunno. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html