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

[Richard Hartmann]

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.

>   (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.


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

Correct.


>  - 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.


>  - 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. That would be stupid and shooting my own foot will always be
possible. And yes, always have one repo per program. I even split up
git & gitk...


>  - Zero issues with .gitignore

Agreed, but my version of vcsh will fix that soonish.


>  - 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.


>  - 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?


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

Again, shooting your own foot will always end up in a shot foot.


>  - 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.


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

I did not look at stow, so no idea.

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.


Richard