Thanks for your reply! (thanks to madduck, RichiH, Antonio also).

On 06/27/2015 12:17 AM, John Whitley wrote:
> Hi Sitaram,
> This is tricky.  vcsh’s approach to overlaying fundamentally relies on
> having multiple git indexes available, one for each separate *working

Yes; my mistake was asking before trying vcsh :-)  I now realise what
it's doing.

Without sending replies to each of the folks who responded here's a
brief outline of why I asked this.  This is just FYI; I consider the
question answered and closed :-)

At present I use something I wrote called "gaf" [1].  It works quite
well, even system config (there's a section in the README about that if
you're curious).  The only problem I have is when something that was
tracked, gets *deleted* and is no longer in the repo.  I was hoping to
learn some tricks from vcsh to deal with that, but found that it uses
different repos for different features.

This is not a show-stopper per se, but I don't really need the full
power of a very generalised, highly customisable, tool like mr so I'd
rather avoid it.



> directory*.  This implies a separate .git directory (or in vcsh’s
> case, a separate bare repo, e.g. “vim.git”) for each overlay.  It
> doesn’t matter whether you’re working with multiple branches or
> multiple remote repos, each workdir must have a .git dir.
> However, there is hope.  Check out the git-new-workdir script in git’s 
> contrib folder.  There’s some discussion of it on Stack Overflow, here:
> From the SO comments:  "It appears to instantly share history and branches 
> between two different checked out repositories with no pushing/pulling, only 
> symlinking.”  That looks close to what I’m guessing you want.
> I suspect it's not all the way there for vcsh’s purposes, since it creates 
> separate full working directories vs. vcsh’s separate dir approach.  But this 
> script probably gets you very close to creating a set of 
> ~/.config/repo.d/{vim,bin,whatever}.git directories that all shared the 
> relevant histories but gave you the separate branches and indexes you want.
> I’ll recommend creating a bootstrap script that does the initial clone and 
> setup for you, since the initial setup will be a touch involved.  See the 
> “bootstrap” branch of my vcsh-root repo for ideas:
> I can grab and run the bootstrap script from github, which sets up my 
> environment using vcsh-root’s master branch as the starting point for my vcsh 
> configuration.  The master branch stores the initial vcsh configuration and a 
> minimal baseline of tools (esp. ~/local/bin/vcsh).  This pattern would give 
> you a place to store the git-new-workdir script, which isn’t guaranteed (or 
> even likely) to be included in most distro’s git builds. Even better, if you 
> need to customize that script for your needs, it’s easy to do in your own 
> root repo.
> Using a bootstrapper script like this makes it trivial to setup a new dev box 
> or VM with as much (or little) of my working environment as I need.
> Good luck!
> John
> P.S. I will now meditate on the fact that this would all be nigh trivial if 
> Plan 9’s filesystem, 9P, had become a ubiquitous feature of *nix systems.
>> On Jun 26, 2015, at 10:32 AM, Sitaram Chamarty <> wrote:
>> On 06/26/2015 10:44 PM, Richard Hartmann wrote:
>>> Vcsh does support branches.
>>> That being said, if you switch from branch zsh to branch vim, you will 
>>> delete the copies of your zsh config in $HOME.
>> Is that a documented feature or an accidental one and might it change in
>> future?
>>> That is most likely not what you want...
>> Indeed :)
>> I was hoping for a way to put everything in one *repo*, and -- one any
>> new machine I come to -- I would just pick a bunch of branch names,
>> depending on what features that machine/user should have.  A bit more
>> convenient (than "mr" or such tools).
>> _______________________________________________
>> vcs-home mailing list

vcs-home mailing list

Reply via email to