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

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

[Richard Hartmann]

Hi all,


some of you may be familiar with fake bare git repositories[1].

Basically, they allow you to keep the git directory and its working
directory separate from each other. This allows you to have an
arbitrary number of repositories with working trees in $HOME. That, in
turn, allows you to have one repo for zsh, one for vim, one for git,
etc pp.

vcsh[2] is a front-end for dealing with fake bare git repos, i.e. it
saves you a lot of typing and automates many things. It's written in
pure POSIX shell.


vcsh's userbase is slowly expanding and as it's feature set and syntax
are stable and there are no known bugs I think this is a good time to
try to increase adoption rate. I strongly believe that a lot of people
on this list could benefit from using it; hopefully you agree.
Publishing it here makes sense as if you are reading this, you are
obviously familiar with and using git already, anyway.

Feedback is very welcome. Good, bad or indifference, I will take it all.

Two notes:

* There is no test suite, yet. If anyone has a suggestion as to which
test suite has a reasonable feature set while having a syntax that
does not make you violently sick, or is even interested in helping to
write said test suite, do let me know.
* I am pondering renaming/aliasing vcsh to git-fbare.sh or similar.
That has a few issues, though..
** extra typing involved
** adds another command level of to otherwise standard git commands,
for example `git fbare zsh commit -a -m 'new feature'`
** forces everyone to have a default location for vcsh repos


Regards,
Richard

[1] http://lists.madduck.net/pipermail/vcs-home/2011-April/000378.html
[2] https://github.com/RichiH/vcsh

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

[Sitaram Chamarty]

On Tue, Dec 20, 2011 at 5:47 AM, Richard Hartmann
<richih.mailinglist@gmail.com> wrote:
> Hi all,
>
>
> some of you may be familiar with fake bare git repositories[1].
>
> Basically, they allow you to keep the git directory and its working
> directory separate from each other. This allows you to have an
> arbitrary number of repositories with working trees in $HOME. That, in
> turn, allows you to have one repo for zsh, one for vim, one for git,
> etc pp.

My method is to put everything in one repo (I call it "hobbits" --
little things that save the world, heh).

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.  Even my
"irssi" settings are tied into that, because of certain macros I use
to reply quickly to queries.

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.

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.

Just offering a different perspective.

regards

sitaram

>
> vcsh[2] is a front-end for dealing with fake bare git repos, i.e. it
> saves you a lot of typing and automates many things. It's written in
> pure POSIX shell.
>
>
> vcsh's userbase is slowly expanding and as it's feature set and syntax
> are stable and there are no known bugs I think this is a good time to
> try to increase adoption rate. I strongly believe that a lot of people
> on this list could benefit from using it; hopefully you agree.
> Publishing it here makes sense as if you are reading this, you are
> obviously familiar with and using git already, anyway.
>
> Feedback is very welcome. Good, bad or indifference, I will take it all.
>
> Two notes:
>
> * There is no test suite, yet. If anyone has a suggestion as to which
> test suite has a reasonable feature set while having a syntax that
> does not make you violently sick, or is even interested in helping to
> write said test suite, do let me know.
> * I am pondering renaming/aliasing vcsh to git-fbare.sh or similar.
> That has a few issues, though..
> ** extra typing involved
> ** adds another command level of to otherwise standard git commands,
> for example `git fbare zsh commit -a -m 'new feature'`
> ** forces everyone to have a default location for vcsh repos
>
>
> Regards,
> Richard
>
> [1] http://lists.madduck.net/pipermail/vcs-home/2011-April/000378.html
> [2] https://github.com/RichiH/vcsh
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Sitaram

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

[Richard Hartmann]

On Tue, Dec 20, 2011 at 03:25, Sitaram Chamarty <sitaramc@gmail.com> 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