Re: Keeping your dotfiles in git

[Benjamin M. A'Lee]

On Wed, Aug 27, 2008 at 01:28:47PM +0100, martin f krafft wrote:
> This works reasonably well for me, but I have yet to figure out how
> to deal with .gitignore.

I've been using a repository layout based on an earlier email you sent
to the list; I keep gitignore files in ~/.var//gitignore and set
core.excludesfile (relative to the worktree, i.e. ~).

-- 
Benjamin M. A'Lee || mail: [EMAIL PROTECTED]
web: http://subvert.org.uk/~bma/ || gpg: 0xBB6D2FA0


signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Keeping your dotfiles in git

[martin f krafft]

also sprach [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008.08.26.2255 +0100]:
> 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/.

I found this too ugly and cumbersome and never liked the redundancy
a script would introduce, or the mess of symlinks cluttering ~.

Therefore I started to experiment with "detached worktrees" with
Git. The concept is easy: ~/dotfiles/vim.git is what I call
a fake-bare Git repository (meaning ~/dotfiles/vim.git/config holds
the Git config, but core.bare is false), with core.worktree set to
../../. As a result, ~/.vimrc is actually a plain file versioned in
the repository at ~/dotfiles/vim.git.

This works reasonably well for me, but I have yet to figure out how
to deal with .gitignore.

Also, to commit or otherwise interact with the vim repository,
I have to set $GIT_WORK_TREE and $GIT_REPO accordingly prior to any
command using /usr/bin/git. At the moment, I am using a script
called vcsh[0] for that, which spawns a subshell with these
variables set (and the $PS1 modified to help me keep track), and
I am actually liking it a lot, even though at first I tought this
explicit "context-switching" would quickly get on my nerves.

0. http://git.madduck.net/v/etc/zsh.git?a=blob;f=.zsh/func/vcsh;hb=HEAD

The approach has the advantage that my /bin/ls -l output is not
polluted with a lot of symlinks, and that I can tell someone else to
look at e.g. http://git.madduck.net/v/etc/zsh.git?a=tree and know
immediately what goes where. No explanation, no script, no
redundancy, little room for failure.

Joey's mr script knows how to deal with "fake-bare" Git
repositories, so "cd ~/dotfiles/vim.git && mr commit" will work as
expected, as will "cd ~/dotfiles && mr update".

As mentioned before, the problem is simply that in the context of
~/.git or ~/dotfiles/vim.git a file like ~/.mutt/muttrc is "unknown"
and will show up in git-status output. One way to deal with that is
to put stuff like

  /*
  !/.vimrc
  !/.vim

into ~/dotfiles/vim.git/info/exclude, but unfortunately, that has to
be done on every machine and cannot be synchronised. It would be
possible to version ~/.gitignore.d/vim in ~/dotfiles/vim.git and set
core.excludesfile in ~/dotfiles/vim.git/config, but that too is
something that has to be done on all machine and won't be
synchronised.

There's also an issue with certain Git repositories requiring
post-processing after cloning and merging (see
http://git.madduck.net/v/etc/ssh.git?a=tree;f=.ssh;hb=HEAD for an
example, which uses make to generate the configuration actually used
by SSH). This can either be done with something like mr, but it's
hackish, or with ~/dotfiles/ssh.git/hooks/update, but that isn't
versioned or synchronised.

Maybe someone has an idea how to deal with those issues?

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

Many "editors" don't respect hardlinks and would unlink them,
causing your files in ~ to become detached from the Git-versioned
files.

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

I have ~ at 711 and a umask of 077 and have been happy so far.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"nothing can cure the soul but the senses,
 just as nothing can cure the senses but the soul."
-- oscar wilde
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Keeping your dotfiles in git

[chombee]

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 po

Re: Keeping your dotfiles in git

[Aristotle Pagaltzis]

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-08-27 00:00]:
> I fail to see the point in having a dotfiles directory. […] Why
> not just create the git repository directly in your homedir?

For Subversion there might not be a point. For git and most other
DVCS, there is: since it tracks trees and not files, unrelated
sets of files should go into separate repositories.

So you then end up with one repo for all the vim dotfiles,
another with your muttrc, and so on, each of which needs to be
a separate directory. Putting those all directly into $HOME is
messy.

Also, if you want to get fancy, you can use a script wrapper
around `git pull` that turns the symlinks into copies before
pulling and deletes the copies and recreates the symlinks
afterwards – but only if the merge succeeded. That way, your
apps and tools never encounter config files with conflict
markers in them.

> Second, to create all the symlinks you only need a simple
> command not a script: `ln -s ~/dotfiles/* ~/`.

It’s nice not to have leading dots in the filenames of dotfiles
within the repository, so the command has to be more complex than
that.

Also, when you split out sets of dotfiles into different repos,
you end up with things like `~/dotfiles/vim/vimrc` which needs to
be symlinked, but where `~/dotfiles/vim` itself also corresponds
to `~/.vim` instead of having a `.vim` subdirectory (because,
again, it’s nicer not to have to work around dotted filenames
when working in the repo).

All this makes the linking complex enough that you don’t want to
type it by hand over and over.

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

You can’t hardlink directories so it’s a moot point either way,
but with symlinks you can also do an `ls -l` and immediately see
which files are under version control: they are symlinked
somewhere below `~/dotfiles/`.

Regards,
-- 
Aristotle Pagaltzis // 
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Keeping your dotfiles in git

[Joey Hess]

[EMAIL PROTECTED] wrote:
> Second, to create all the symlinks you only
> need a simple command not a script: `ln -s ~/dotfiles/* ~/`.

That won't deal with dotfiles that are renamed or deleted.
 
> 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.

I've had better luck with sylinks (various things can accidentially
break a hard link, in a non-obvious way), but do have to use hardlinks
for a few things. IIRC fetchmail refuses to use a symlink for example.

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

I have several dotfiles that I don't want to share to every machine with
a checkout of my home directory, so need multiple repositories.
 
-- 
see shy jo


signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Keeping your dotfiles in git

[chombee]

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