to symlink or not to symlink (was: Re: various suggestions for mr)

[Adam Spiers]

So with the direction this subthread is going, it seems a good time
to ask everyone:

   (a) Are your ~/.* files symlinks or not?
   (b) Why?

I get the impression that some people on this list prefer to use git's
detached working trees feature, e.g.

  http://www.mail-archive.com/vcs-home@lists.madduck.net/msg00078.html

so I'm interested to understand the reasons behind this preference.
As I see it, the benefits of using a symlink manager like GNU stow
are:

  - You can immediately see which files under ~ are managed by it.

  - You can immediately see which stow package any symlinked file
    under ~ belongs to, e.g.

       lrwxrwxrwx. 1 adam adam 21 Oct 20 10:20 /home/adam/.zshrc ->
.cfg/shell-env/.zshrc

  - Zero issues with .gitignore

  - No extra effort required to prevent other tools such as
    dvcs-autosync getting confused by having unrelated files in the
    working directory.

  - No need to use something like vcsh to temporarily and manually
    adjust git environment variables to point the correct bare repo
    (and this approach doesn't work anyway if you like to commit from
    within a long-running editor process).

  - Highlights file conflicts between packages which could otherwise
    cause confusion.

  - Ties in nicely with the UNIX way of one tool per job: mr manages
    the layer of interaction with "upstream" repositories, and
    integrates via action hooks with the symlink manager which manages
    the local "package" layer.

But I'm sure there are some disadvantages too.  Anyone care to
elaborate?

Cheers,
Adam

On Fri, Oct 28, 2011 at 2:34 PM, Adam Spiers <vcs-home at adamspiers.org> wrote:
> On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck <dieter at plaetinck.be> wrote:
>> Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up and it seems very nice.
>> i haven't run it yet, but (for those who don't want to read the long description) from the description it seems like a simple and elegant tool,
>> which you give a directory ("i want symlinks here") and a bunch of package directories ("all files in here must be symlinked")
>> and it will do the right thing on package additions and removals.
>
> Yes, it is pretty nice (although the code base is very old-fashioned).
>
> One thing it does which I guess other symlink managers wouldn't, is
> called "tree folding" - i.e. it makes intelligent decisions about when
> to symlink to a subdirectory vs. to individual files within that
> subtree:
>
>  http://www.gnu.org/software/stow/manual.html#SEC4
>
> For example, imagine I have a stow package called 'foo' which wants to
> install a file to ~/local/lib/perl/Acme/Foo.pm (by "install", I mean
> set up a symlink so that that path points to the Foo.pm inside the
> stow package).  If ~/local doesn't already exist, and 'foo' is the
> only stow package which installs anywhere under ~/local, then stow's
> tree folding feature will ensure that ~/local is a symlink back to
> $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.
>
> However I might very well want to manually place other files inside
> ~/local which have nothing to do with stow, let alone the 'foo' stow
> package.  It might make sense to have ~/local/lib/perl/Acme/ be a
> symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
> the tree would be undesirable.  This is easily overcome by creating a
> special stow package (which I call 'ANTIFOLD') which contains (empty)
> dummy files called .no-stow-folding in those trees.  So I run a simple
> little custom shell script:
>
>    $ unfold ~/local/lib/perl5
>
> which creates an empty file
>
>    $STOW_DIR/ANTIFOLD/local/lib/perl5/.no-stow-folding
>
> and (re)installs the 'ANTIFOLD' stow package, which causes stow to
> automatically "split" the ~/local/lib/perl5 tree open so that
>
>    ~/local/
>    ~/local/lib/
>    ~/local/lib/perl5/
>
> are all normal directories, and ~/local/lib/perl5/Acme becomes the
> symlink.  Problem solved!
>