On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote: > On 07/12/18 10:52, David Wright wrote: > > On Mon 09 Jul 2018 at 20:33:00 (-0700), David Christensen wrote: > > > On 07/09/18 11:17, Ge wrote: > > > > Should i make a different partition for /home/ ? > > > > > > I don't -- I put my bulk data on a file server, including all e-mail > > > attachments. My home directory is ~1 GB. > > > > > > > > > (If/when I want to travel with my laptop, I will need to figure out > > > how to set up a VPN to my file server.) > > > > I would find that rather risky, so I have a "proper" separate, > > encrypted /home that ranges from 50GiB (laptop) to ~400GiB > > (desktops)—basically, the rest of the drive, though one laptop > > gives a fair amount of space over to a W10 installation. > > First, I will need to test how the applications I use react to VPN > connections going up and down. > > > My file server is also a CVS server. This makes it easy to keep the same > files on multiple computers, and to > synchronize changes. (CVS can solve the three-way merge problem for text > files. I need to be mindful when editing > binary files.)
I've completely replaced CVS with git these days - for all my hacking of course, as well as parts of home/ - and I finally figured out how to have a inter-system (or -drive) "git update" work "properly" by which I mean: - some repos I am interested in, I grab into home/setups-local with a quick git clone git://repo... repo.gits - Everything ultimately gets backed up onto a file server, on which when I'm working I grab a repo with git clone --mirror git://repo... repo.gitm - The repo.git[ms]/.git/configs need to do the following: a) in whichever repo I am in/ updating (by script or otherwise), I want a "git fetch" or "git pull" to Do The Right Thing (TM)(C)(R), which means: b) it MUST first get all possible updates from the "other" instance that I maintain of that repo, including my own personal branches etc c) only THEN must it download remaining updates from the net and so to achieve this, the .git/config files look somewhat like this: # ~/setups-local/postgresql.gits/.git/config : [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "setups"] # fetch from "setups" url = /setups/p/postgresql/postgresql.gitm fetch = +refs/remotes/origin/*:refs/remotes/setups/* [remote "origin"] url = git://github.com/trevorbernard/disruptor-examples.git fetch = +refs/*:refs/remotes/origin/* fetch = +refs/heads/*:refs/heads/* fetch = +refs/tags/*:refs/tags/* [branch "master"] remote = origin merge = refs/heads/master # /setups/p/postgresql/postgresql.gitm/config : [core] repositoryformatversion = 0 filemode = true bare = true [remote "setups-local"] # fetch from "setups-local" url = /home/me/setups-local/postgresql.gits fetch = +refs/remotes/origin/*:refs/remotes/setups-local/* [remote "origin"] url = git://git.postgresql.org/git/postgresql.git fetch = +refs/*:refs/remotes/origin/* fetch = +refs/heads/*:refs/heads/* fetch = +refs/tags/*:refs/tags/* # fetch = +refs/pull/*:refs/remotes/origin/pull/* # fetch = +refs/pull/*:refs/rpull/origin/* [remote "pgxc-sf"] url = git://postgres-xc.git.sourceforge.net/gitroot/postgres-xc/postgres-xc fetch = +refs/heads/*:refs/remotes/pgxc-sf/* fetch = +refs/tags/*:refs/rtags/pgxc-sf/* [remote "pgxc"] url = git://github.com/postgres-x2/postgres-x2.git fetch = +refs/heads/*:refs/remotes/pgxc/* fetch = +refs/tags/*:refs/rtags/pgxc/* [remote "pgxc-docs"] url = git://github.com/postgres-x2/implementationDocs.git fetch = +refs/heads/*:refs/remotes/pgxc-docs/* fetch = +refs/tags/*:refs/rtags/pgxc-docs/* [remote "pgxc-webpage"] url = git://github.com/postgres-x2/webpage.git fetch = +refs/heads/*:refs/remotes/pgxc-webpage/* fetch = +refs/tags/*:refs/rtags/pgxc-webpage/* [remote "pgxc-github.io"] url = git://github.com/postgres-x2/postgres-x2.github.io.git fetch = +refs/heads/*:refs/remotes/pgxc-github.io/* fetch = +refs/tags/*:refs/rtags/pgxc-github.io/* [remote "pgxl"] url = git://git.code.sf.net/p/postgres-xl/postgres-xl fetch = +refs/heads/*:refs/remotes/pgxl/* fetch = +refs/tags/*:refs/rtags/pgxl/* [remote "pgxl-tools"] url = git://git.code.sf.net/p/postgres-xl/tools fetch = +refs/heads/*:refs/remotes/pgxl-tools/* fetch = +refs/tags/*:refs/rtags/pgxl-tools/* In this way, I can update one, then update the other, and I don't download the updates twice. Yes, each holds an extra set of heads, tags etc under remotes/setups/ and remotes/setups-local/ respectively, which not only is a very small "price" to pay, but has actually been useful once or twice when I've messed around with tags and heads, gotten befuddled and ultimately had to go check the local "origin" duplicate refs in setups or setups-local, to fix things up. This took me a few attempts, a coupla bungles and many googoyle searches and man page readings, over a year and half, before I finally got it right. The main problem (besides understanding enough of remotes and refs) was duplicating the "other" mirror (setups and setups-local respectively, in the above example) into the current mirror, without building a deeper and deeper refs hierarchy due to the inherently recursive tags hierarchy creation with something simple such as: [setups] fetch = +refs/*:refs/remotes/origin/* [setups-local] fetch = +refs/*:refs/remotes/origin/* which would cause an ever-deepening refs hierarchy each time I swapped from one mirror to the other. Using fetch = +refs/remotes/origin/*:refs/remotes/setups/* instead, solves this particular problem - but also means one must add lines such as the following: fetch = +refs/heads/*:refs/heads/* fetch = +refs/tags/*:refs/tags/* in order for the repo to "work" normally. Note also my "setups" mirror includes a bunch of other repos which relate to postgresql - that way, common files are not duplicated across many local mirrors, instead they're all in a single mirror - this is particularly useful when one is mirroring various forks of a large repo, such as Linux kernel. Use commands such as the following to add an additional remote repo, to a local mirror: git remote add <name> <url> And then you can use <name> to checkout branches, or create work dirs (a nice feature in recent versions of git). Enjoy,
