Re: Introducing vcsh - manage config files in $HOME via fake bare git repositories

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 20, 2011 at 03:25, Sitaram Chamarty <sitaramc@xxxxxxxxx> wrote:

> My reasoning is that nothing is an island.  I am a heavy user of vim,
> fugitive (git plugin for vim), tig, and ranger, and at least these 4
> are linked to each other.  You could argue that I should use
> submodules or gitslave or something but I keep it simple.

Or mr[1]. That's _exactly_ what mr is for.


>  Even my
> "irssi" settings are tied into that, because of certain macros I use
> to reply quickly to queries.

I doubt you want to keep your IRC passwords on a work machine, for
example. If you need repos to be together, check them out together.
But I doubt you want _everything_ _everywhere_.


> There's a piece of my ".additional.bashrc" that automatically symlinks
> everything that are best left in $HOME (like ~/.gitconfig) and sets up
> environment variables for everything else (like TIGRC_USER) that can
> get along without.

Symlinks are unclean, imo.

Personally, I like to use .zshrc.$HOSTNAME for local stuff. This sorts
more nicely than .$HOSTNAME.zshrc .


> There are 2 helper scripts.  One packs all of this into a tarball so I
> can easily untar it on any machine on which I have to work
> temporarily, and the other cleans up the unpacked directory and
> symlinks when I leave.

Cloning from public repos seems to make more sense, especially if you
make local changes.


> Just offering a different perspective.

Appreciated. It's always great to know how others are approaching this.


Richard
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]