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

[Adam Spiers]

On Fri, Oct 28, 2011 at 4:09 PM, Richard Hartmann
<richih.mailinglist at gmail.com> wrote:
> On Fri, Oct 28, 2011 at 16:14, Adam Spiers <vcs-home at adamspiers.org> wrote:
>
> FYI: My version of vcsh [1] is different from madduck's. He graciously
> agreed to let me have the name and may switch over to my
> re-implementation soon from what I heard from him.

Ah thanks, I did wonder about that.

>>   (a) Are your ~/.* files symlinks or not?
>
> Not any more.
>
>>   (b) Why?
>
> It seems unclean, at best. I generally try to avoid symlinks where
> possible. There are very valid use cases for links (soft: git-annex,
> hard: some backup schemes, sharing funny pics etc on shared disks,
> cloning a directory to work with it iin git-annex while keeping the
> old directory full intact...) but this is not one, imo.
>
> It comes down to preference.

Sure, there's no right and wrong.  It sounds like your preference is
based on a sense of aesthetics rather than more concrete technical
arguments?  Not that there's anything wrong with that - aesthetics are
important too.  But if you are aware of some specific technical
advantages of avoiding symlinks, I'd be very interested to hear them
so that I can weigh them up against the alternative.

>>  - You can immediately see which files under ~ are managed by it.
>
> for repo in vcsh list; do vcsh run repo git ls-files; done
>
> Alias that away in case that's a valid use case, for you.

Sure, although that's assuming you have a shell to hand.  Almost
always the case, but sometimes it's handy to be able to see with
nothing more than a file manager (e.g. sftp).

More significantly, it doesn't tell you which files are *not* managed
by it.  Without symlinks, you have to iterate over all your
repositories, and then filter out those files from the set of files
you are interested in looking at.

>>  - You can immediately see which stow package any symlinked file
>>    under ~ belongs to, e.g.
>
> See above. But I sincerely doubt that my .vimrc will ever end up in my
> zsh repo.

Well, I'm obviously more prone to mistakes than you ;-) But that
aside, I want this setup to support checkout of a large number of
third party software packages which I'm either trying out, using, or
even collaborating with development.  In that case, there are a large
number of unfamiliar looking files installed in my home directory, so
it's not always immediately obvious where files have come from.

>>  - No extra effort required to prevent other tools such as
>>    dvcs-autosync getting confused by having unrelated files in the
>>    working directory.
>
> Never heard of that, I use mr. And vcsh was written with mr in mind.
> Thus, it integrates nicely.

To clarify, I'm thinking of using dvcs-autosync in parallel with mr,
not instead of it.

>>  - 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).
>
> How is that a disadvantage when a tool hides it from you?

I don't know vcsh well enough to know which tool you are referring to
or what it would hide.  But I can't see how an approach which (in my
very limited understanding) is based on altering environment variables
would work without requiring a restart of my editor.  If you're a vim
user who starts up your editor every time you edit a new file, that
will work fine for you.  But it doesn't gel with my personal workflow.

>>  - Highlights file conflicts between packages which could otherwise
>>    cause confusion.
>
> Again, shooting your own foot will always end up in a shot foot.

Not if there's a bullet-proof barrier in between your gun and your
foot :-)  Which is exactly my point - I'm saying that if you had the
same (relative) file path in two different stow packages, stow will
refuse to install one over the top of the other; instead it will tell
you that you're trying to do something stupid.

>>  - 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.
>
> So does vcsh.

Yeah, I admit that one wasn't a very strong argument against not
having symlinks :)

>> But I'm sure there are some disadvantages too.  Anyone care to
>> elaborate?
>
> I did not look at stow, so no idea.

I meant disadvantages to using symlinks in general.  It doesn't really
matter what method you use for managing symlinks, the end result is
pretty much the same (modulo tree folding).

> One point, though: If i delete my repos, my system continues to work
> as expected. If you do the same, all your configs are gone.

If I did something that stupid, I'd prefer to know about it sooner
rather than later :-)  Besides:

  - An accidental "rm ~/.zshrc" seems much more likely than an
    accidental

      rm -rf ~/path/to/all/my/git/repos/I/rarely/access/directly

    because my pwd is $HOME far more often than anything else.  And in
    the former case, if you are using symlinks, all you lose is a
    symlink, whereas with detached git working directories, you lose
    the whole file which may contain changes not yet in the git index
    or repo.

  - This is git, so all my repos are mirrored remotely.  So at
    worst I would only lose stuff I haven't committed yet.