libera/#shirakumo - IRC Chatlog
Search
9:52:24
Colleen
<SAL9000> shinmera: I recall something about a relatively new (experimental, last I checked) system for partial clones -- i.e. excluding some subfolders while cloning. Not sure if that's what you want but it might be a step in the right direction.
9:54:46
Colleen
<SAL9000> "purely publication" repo which only you are going to change, versus a "full featured" repo where you expect to get changes from people w/o access to the assets
9:55:36
Colleen
<SAL9000> however... I have a similar issue at $dayjob which I've written custom tooling for.
9:56:51
Colleen
<SAL9000> in our case, we have 2 repos -- main & restricted -- similar to your situation
9:57:00
Colleen
<shinmera> The problem would be much easier if the structure were inverted I suppose. Meaning one repo that has the "main source" and the "assets" repos as a subtree.
9:57:05
Colleen
<SAL9000> there are files which are only in main, files which are in both, and files which are only in restricted
9:57:36
Colleen
<SAL9000> the files that are in both -- includes, standard library, etc. -- need to be synchronised
9:58:46
Colleen
<SAL9000> the tool I wrote takes repo A, does the equivalent of git log --full-history --simplify-merges BRANCH -- files/you care/about and creates equivalent commits in repo B.
9:59:54
Colleen
<SAL9000> Assuming you trust the tool you could have it sign commits with your key, I guess?
10:01:29
Colleen
<SAL9000> I use the word "survive" for a reason -- say you "delete" a commit off the tip of a branch, it won't propagate that.
10:02:12
Colleen
<shinmera> I think having the 'main repo with two subtrees' is the easiest to setup. I can just rewrite my tooling to support that case.
10:04:31
Colleen
<shinmera> Ah, I wasn't aware the commit IDs would be different when pushing to a subtree
10:05:12
Colleen
<shinmera> SAL9000: I'm aware that the subtree's commits are part of the main repo's history
10:05:26
Colleen
<SAL9000> As far as I understand, subtrees are basically normal commits except with some mail-header-style tags in the merge commits.
10:06:09
Colleen
<SAL9000> So, you'll have subtree-commits interspersed with non-subtree commits (or those of other subtrees) -- so, omitting those will force you to rewrite parents
10:06:27
Colleen
<SAL9000> If you're careful you could maintain the subtree as its own root, I guess?
10:07:20
Colleen
<SAL9000> Also, I suspect that existing subtree tooling will do rewrites as the lazy way out.
10:08:36
Colleen
<shinmera> I mean, as long as a commit doesn't touch both the subtree and the non-subtree in one I don't see any issues
10:09:36
Colleen
<SAL9000> Same. The moment I say subtree/submodule all my co-workers run away screaming.
10:10:14
Colleen
<SAL9000> Ditto for "we should preserve VCS history" as in, from the pre-Git dark days when we used Perforce.