"Matt Seitz (matseitz)" <matseitz@xxxxxxxxx> wrote: > The git-update-index and git-update-ref manual references are the > closest to what I was looking for. Both are more low-level and > technical than what I was hoping for, and the discussion in > git-update-index seems targeted primarily at how symlinks are translated > on file systems that don't support symlinks. > > I guess I was looking for something like the GNU "tar" documentation of > how symlinks are handled > (http://www.gnu.org/software/tar/manual/html_node/dereference.html#deref > erence). Git never dereferences a symlink that are stored as part of the revision data. The only time we dereference a symlink is when it is used inside of .git/refs, or as .git/HEAD, which is what the git-update-ref manpage was talking about. So Git handles symlinks in the working tree *without* dereferencing them. Internally we store the target of the symlink, much as tar would store the target of the symlink. There is no way to activate a dereference behavior (--dereference / -h in GNU tar) as typically you want to preseve the symlink as a symlink to the target; its part of your source code. Maybe this is a good hint that the user manual should have a section on symbolic links. Its obvious to old Git hands that a symlink is nothing more than a file with a slightly different mode, but that may not be obvious to people who are new to Git. -- Shawn. - 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
