tynet-lichat/shirakumo - IRC Chatlog
Search
9:52:24
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
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:57:00
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
SAL9000
there are files which are only in main, files which are in both, and files which are only in restricted
9:57:36
SAL9000
the files that are in both -- includes, standard library, etc. -- need to be synchronised
9:58:46
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.
10:01:29
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
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:05:25
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
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:07:20
SAL9000
Also, I suspect that existing subtree tooling will do rewrites as the lazy way out.
10:08:36
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:10:13
SAL9000
Ditto for "we should preserve VCS history" as in, from the pre-Git dark days when we used Perforce.