Ok, I see the points regarding why you should use symlinks, why it's worth
putting things in a dotfiles directory, and why you can't just use a
single ln command to create the symlinks. I wonder what you should use
instead then? A simple script seems to be in order. If I were to write a
script I would write it in Python because that's what I know, and I have
seen many scripts for this purpose that people have written in Python or
Ruby, but then that assumes Python or whatever is on the system you're
using. I'm trying to keep things as simple and minimal as possible. I've
seen various types of makefile that people have created, but those seem to
require maintenance, e.g. adding a line to the script each time you add a
new file to the repo. I want zero maintenance. A bash script then? I'm not
a bash-scripter but I found one that someone had posted for this purpose:
$DIR=~/dotfiles/
cd $DIR
for i in *; do ln -s $DIR/$i ~/.$i; done
and it's simple enough that even I can see exactly how it works. (Also I
have to say, it is _much_ shorter than the Python and Ruby scripts I've
seen.) Although presumably you want to keep the script itself in the repo,
and therefore the script needs an exception so that it does not symlink
itself. But doesn't even a bash script assume your shell is bash? I
suppose that's a fairly safe assumption, if bash is the shell you use, it
does seem to be the default on most unix-like systems (I don't recall
seeing one with any other default, except sdf.lonestar.org which uses sh
by default IIRC.)
I'm not sure I would want to create different repos for dotfiles belonging
to different programs (as I think Aristotle was suggesting?), that would
make things more complicated, even though I see that you keep all your
repos in subdirs of a dotfiles dir so they're all in one place. I would
only want to use multiple repos if there were some dotfiles that I wanted
to be present on some machines and not others. (And I'd actually try to
avoid that complication too unless I really needed it.)
So you need a dotfiles directory that contains the repo, and some script
for creating symlinks in your home directory. That seems simple enough so
far, as long as the script can be simple and minimal and, hopefully,
require no maintenance.
The final point is what's bugging me about this after writing the first
email, if you're going to keep your dotfiles in a public repo (which is
the most convenient thing, because free public hosting is available), then
you
really want to snip out any private data. I'd be perfectly happy to post a
muttrc with the lines that contain private info at the top and modified
like this:
set folder="imaps://your.imap.server"
set [EMAIL PROTECTED]
etc. But then as soon as you check that out you're going to want to modify
those lines, and then the file is gonna start showing up in git status
when you don't want it to. Rats.
Trying to think of a workaround. muttrc files can include other muttrc
files, so you could have one file for all the non-private stuff and
another for the private lines, then only the private file shows up in your
git status after you've modified it, and you just ignore it. But probably
not all config files allow you to do that.
I guess the ultimate conclusion may be that private hosting is really what
you need for certain dotfiles.
> I was doing this briefly in the past (and spoke about it on this list),
> but the system I setup was too awkward and it soon got left behind. Now
> I'm revisiting the idea, and I want to do it in as simple and convenient a
> way as possible. For one thing, I'm planning on using GitHub as the
> central server to keep my dotfiles, as lots of people are doing. But also,
> I've been looking at the strategies people use and trying to distill the
> simplest possible approach.
>
> Google and you can find lots of people who keep their dotfiles in a git
> repository. Usually they create a directory such as ~/dotfiles/ and they
> move all the dotfiles they want to track into that directory, and create
> the git repository in that directory. Then they have a script of some kind
> (I've seen scripts in half a dozen languages for this) that creates
> symlinks from the root of their homedir into their dotfiles directory,
> e.g. linking ~/.muttrc/ to ~/dotfiles/muttrc/.
>
> This seems pretty simple to me, although I don't see why a script is
> necessary to create the symlinks. First, when the files in your dotfiles
> directory are symlinked into your homedir, then you can simply edit the
> files as if they were in your homedir, e.g. `nano ~/.muttrc`, and the
> changes you make will show up when you do `git status` in your dotfiles
> directory, that's convenient. Second, to create all the symlinks you only
> need a simple command not a script: `ln -s ~/dotfiles/* ~/`.
>
> I'm not entirely clear on why, in the examples I've seen, the -s option is
> used to create symbolic links instead of just using hard links.
>
> Also, I fail to see the point in having a dotfiles directory. It might
> make it easy to break things up into generic dotfiles that apply to all
> machines that you use and go in the dotfiles directory, and dotfiles that
> are only used on particular machines and go in various
> dotfiles-machinename directories. But aside from that, why not just create
> the git repository directly in your homedir? Give it a .gitignore file
> that ignores everything (contains one line with just a *), then add to the
> repo only the files you want to version with commands like `git add -f
> ..muttrc`.
>
> What about the permissions of your dotfiles? Git does not track file
> permissions, except for the executable bit, so people often create scripts
> to somehow store and restore the permissions of all the files. But I don't
> see that this is a problem. Files created by git will have permissions
> according to your UMASK environment variable, on my system they will be
> readable by everyone, writable only by you, and executable by no one.
> Files that you have made executable and committed into the repo will
> maintain their executable bits when created or overwritten by git, but you
> shouldnt find yourself using this feature if you're just tracking
> dotfiles.
>
> So that means that your dotfiles _will be readable by anyone_, if your
> UMASK is the same as mine. If you don't want that, then you should just
> change your UMASK. But it seems to me that there's nothing wrong with them
> being readable. Lots of people even share their dotfiles now, on GitHub,
> for example. As long as, obviously, you don't put passwords or other
> private information into any of the dotfiles that you are tracking. This
> shouldn't be too much of an inconvenience. If I want to track my .muttrc,
> for example, and keep it in a public repo on GitHub, I think I'd be
> perfectly happy to put my imap and smtp servers and usernames in there,
> but just omit the password. (Which is what I do anyway, I don't want to
> store passwords in files on my machine and then have to worry about the
> machine being secure.) The only problem I can think of is that putting my
> email address in a config file such as muttrc then committing it to a
> pulbic GitHub repository might make it available to spammers.
>
>
>
>
> _______________________________________________
> vcs-home mailing list
> vcs-home@lists.madduck.net
> http://lists.madduck.net/listinfo/vcs-home
>
_______________________________________________
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
