I just landed an update for my homedir repos that enables the use and 
bootstrapping of vcsh hooks.  This in turn enables sparse checkouts (e.g. for 
keeping per-repo README files out of $HOME) and other custom repo settings 
(esp. `git config pull.rebase true`).

I posted in a GitHub issue thread with some related discussion:

https://github.com/RichiH/vcsh/issues/120#issuecomment-119377499 
<https://github.com/RichiH/vcsh/issues/120#issuecomment-119377499>

I’ve replicated the comment below, slightly reformatted for email, since I 
recall there are folks with limited bandwidth who may not want to hit GitHub 
and/or for discussion here.

— John

-------------

I *finally* went through the setup of vcsh hooks and sparse checkout for my 
setup.  I took a slightly different route than @vdemeester and @marklee77.  
Instead of loading up the bootstrap script with the hooks that must be run on 
the "root" repo, I use some extra `mr.post-clone.*` style symlinks to ensure 
that my root repo (which vcsh knows as `mr` for historical reasons) gets 
everything run on it the first time out.  See jwhitley/vcsh-root@30b0d49 
<https://github.com/jwhitley/vcsh-root/commit/30b0d495c2cbe47ae9617ace9c2c14720d961d78>[1],
 and jwhitley/vcsh-root@3dc9057 
<https://github.com/jwhitley/vcsh-root/commit/3dc9057f421a3829fbc30bf0c33df27a61bad229>[2]
 for examples.

The nice thing about this approach is that the bootstrap script takes on only a 
one line change[3], to do the retroactive sparse checkout cleanup: `vcsh mr 
read-tree -md HEAD`.  After that, the hooks are all in place and `mr update` 
invokes vcsh on the remaining child repos correctly.

If I ever got too many hooks in place, it'd be easy enough to run `vcsh upgrade 
mr` in the bootstrap script and remove the extra `mr.*` symlinks.

It'd be interesting to bake out a simplified vcsh-only demo root repo that 
incorporates just (e.g.) the `core.sparseCheckout` and the `pull.rebase` 
settings.  It's a little unclear how to best do this: maybe just `vcsh clone` a 
whole list of repos in the bootstrap script or maybe in 
`root.post-clone-retired.00-clone-child-repos`?  vcsh itself doesn't have a 
concept of available-but-uncloned repos AFAICT; that's been mr's job in setups 
like mine.

Last but not least, hat tip to @marklee77 for having a Vagrantfile around and 
using sparse checkout to ignore it.  Brilliant, and I've adopted that in 
slightly different forms in the `master`[4] and `bootstrap`[5] branches' 
Vagrantfiles.  The `master` version uses an inline-modified bootstrap script to 
clone the *local* repo into the VM's homedir for testing.  The `bootstrap` 
version uses the *local bootstrap.sh* to test bootstrap changes vs. the 
existing remote `master` branch.

[1] 
https://github.com/jwhitley/vcsh-root/commit/30b0d495c2cbe47ae9617ace9c2c14720d961d78
 
<https://github.com/jwhitley/vcsh-root/commit/30b0d495c2cbe47ae9617ace9c2c14720d961d78>
[2] 
https://github.com/jwhitley/vcsh-root/commit/3dc9057f421a3829fbc30bf0c33df27a61bad229
 
<https://github.com/jwhitley/vcsh-root/commit/3dc9057f421a3829fbc30bf0c33df27a61bad229>
[3] 
https://github.com/jwhitley/vcsh-root/blob/b7b5947442eef6f8ed94f7aa62f4a11833c732db/bootstrap.sh#L37
 
<https://github.com/jwhitley/vcsh-root/blob/b7b5947442eef6f8ed94f7aa62f4a11833c732db/bootstrap.sh#L37>
[4] https://github.com/jwhitley/vcsh-root/blob/master/Vagrantfile 
<https://github.com/jwhitley/vcsh-root/blob/master/Vagrantfile>
[5] https://github.com/jwhitley/vcsh-root/blob/bootstrap/Vagrantfile 
<https://github.com/jwhitley/vcsh-root/blob/bootstrap/Vagrantfile>

_______________________________________________
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Reply via email to