vcsh: use branches instead of repos?

[Sitaram Chamarty]

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.

[1]: https://github.com/sitaramc/gaf

regards
sitaram

> 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:
> 
> http://stackoverflow.com/a/6270727/183481
> 
> https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir
> 
> 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:
> 
> https://github.com/jwhitley/vcsh-root/tree/bootstrap
> 
> 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 <sitaramc at gmail.com> 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 at lists.madduck.net
>> http://lists.madduck.net/listinfo/vcs-home
>