libera/#shirakumo - IRC Chatlog
Search
8:16:48
Colleen
<shinmera> any git wizards know if there's a way to have git-subtree-like behaviour but have both the "root" and the "sub repo" be entirely separate instances? Meaning I want a central repo A that has both the root and the sub-repo, but also a repo B that is just the root without the sub-repo, and a repo C that is just the sub-repo.
8:17:37
Colleen
<shinmera> if I remember correctly standard subtree means the history of the sub repo is merged into the history of the base repo
8:21:14
Colleen
<shinmera> The reason I want this, to give some context, is that I'd like to separate out the assets folder of Kandria so I can publish the source without assets publicly.
8:21:35
Colleen
<shinmera> But at the same time I can't expect my coworkers to know enough git-fu to fuck around with submodules or subtrees or symlinks or multiple repos
8:22:55
Colleen
<shinmera> So ideally internally we'd have just one repo, and I can selectively push commits that affect the assets to the assets repo.
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.