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 <sitar...@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@lists.madduck.net >> http://lists.madduck.net/listinfo/vcs-home > _______________________________________________ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
