-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathBlik_2026_git
More file actions
110 lines (78 loc) · 8.71 KB
/
Copy pathBlik_2026_git
File metadata and controls
110 lines (78 loc) · 8.71 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
{text-align:justify}
(Remote project composition)#h2
Interface has a "flat" folder structure, meaning no folder structure, but rather an author and year attribution prefix naming convention for modules. Its ability to command modules with arbitrary context allows them to be generic enough that any folder could only limit their meaning, or invert import hierarchies. Classification of such generic modules is possible, but it makes them independent enough that they constitute new projects, where file names are evidently complementary, or ensured by the attribution prefix. It is therefore safe to use interface in any project by merging its files from a new remote:
(interface(){
echo " Stashing local changes in case of conflict..."
stash=$(git status --porcelain|wc -l);
[ $stash -gt 0 ] && git stash;
echo " Merging Interface files..."
git remote add interface https://github.com/blikest/interface;
git fetch interface;
git checkout interface/stable .;
echo " Restoring project scope."
git restore --staged .;
git restore $(git ls-files);
[ $stash -gt 0 ] && git checkout stash -- .;
}
interface
)#div{display:block;width:90%;margin:0px 5%;border-radius:.5em;border:1px solid #43a047;background:black;overflow:scroll;white-space:pre;font-family:monospace;color:#616161}
This leaves your own project files in git's scope, but if you want to contribute to different remotes like this, their ignore file needs to be checked out first to put your changes to its files into scope (imagine switching back to your project and finding it reset by a simple checkout):
(check(){
remote=$1
if [ -z ${remote} ]; then echo "remote: ";read remote; fi
branch=$2
if [ -z ${branch} ]; then echo "branch: ";read branch; fi
echo pivotting to $remote/$branch;
echo "";
git fetch $remote;
git checkout $remote/$branch .gitignore;
git add .;
stash=$(git status --porcelain|wc -l);
[[ $stash -gt 0 ]] && git stash;
git checkout $remote/$branch;
[[ $stash -gt 0 ]] && git checkout stash .;
git restore --staged .;
}
check interface stable
)#div{display:block;width:90%;margin:0px 5%;border-radius:.5em;border:1px solid #43a047;background:black;overflow:scroll;white-space:pre;font-family:monospace;color:#616161}
Treating ignore files as project scope trackers like this proves "monorepo" and "submodule" concepts obsolete, given each project also gives module names the respect described above. Changes can remain "detached" at the remote HEAD, without local branch references. A commit to a local branch reference is only needed in the unlikely case that you intend to inspect the same file for multiple conflicting tasks, or do so offline for an extended time period - otherwise you can manage branches directly on remote references. Since this practice of merging different remotes into the same local repository is a bit unusual, here are some further git commands for awareness of tracked scopes to use beyond the common pull-push-merge on singular remotes:
( git remote -v; # list remotes.
git remote add name url; # add remotes with more specific names than the common "origin".
git remote remove name;
git branch -avv; # list branches with remote information.
git checkout name/branch; # contribute to remote branch without local reference ("detached" HEAD).
git switch -c branch name/branch; # create local branch, eg. eponymous branch of remote tracking its stable branch.
git branch -d branch; # delete local branch (capital -D to discard its commits too.)
git push -d remote branch; # delete remote branch.
git push name HEAD:branch. # contribute to existing branch.
git push name HEAD:refs/heads/branch; # create remote branch.
git pull --rebase; # reapply local commits on remote ones.
git ls-remote --tags interface;
tag=YEAR.MM; git tag -d $tag; git tag $tag; git push $(target remote) :$tag; git push $(target remote) tag $tag;
remote=$(git branch -r --contains HEAD); # tracked remote.
commit=$(git rev-parse HEAD);
)#div{display:block;width:90%;margin:0px 5%;border-radius:.5em;border:1px solid #43a047;background:black;overflow:scroll;white-space:pre;font-family:monospace;color:#616161}
(Git Interface)#h2
The standard UNIX implementation of Git is robust, but these Shell languages to script them are notoriously cryptic, and inconsistent. Isomorphic-git is a javascript implementation that we can use to write these commands instead:
sources#[["/Blik_2023_sources.json"],"interface/fetch","interface/digest",[["Hilton_2017_isomorphic-git.js","Feross_2014_simpleget.js","Schouten_2015_async-lock.js","White_2016_clean-gitref.js","Sheets_2014_crc32.js","Wanek_2016_diff3.js","Kael_2015_ignore.js","Hinosawa_2015_minimisted.js","Puzrin_2014_pako.js","sindresorhus_2015_pify.js","isaacs_2012_readable-stream.js","Tarr_2014_sha1.js","Hilton_2018_lightningfs.js","Hilton_2018_isomorphic-git-http.js"]],"inference/flip","inference/extract","meta/aphorize",[{"source":"/Blik_2023_sources.json","scale":0.8}],"script","script/index"]{background:transparent;max-width:90%;margin:auto;border-radius:.5em; border:2px dashed #616161}#[[2],{"inference/tether":["script/fold"]}]
check#[["/Blik_2026_git.js/module/namespace"],"interface/fetch","interface/digest",[["check"]],"inference/flip","inference/extract",[["exports"]],"inference/record",["module"],"meta/serialize",[{"source":"/Blik_2026_git.js","scale":0.8,"gutter":31}],"script","script/index"]{background:transparent;max-width:90%;margin:auto;border-radius:.5em; border:2px dashed #616161}#[[0],{"inference/tether":["script/fold"]}]
(Semantic checkout)#h2
Everyone has different preferences of writing, but a convention requires us to at least commit it in the same dialect. We can specify this format in the Meta module's serialize#b function, and substitute modularisation from Interface's loading sequence with persistence in a compile#b function:
compile#[["/Blik_2023_interface.js/module/namespace"],"interface/fetch","interface/digest",[["compile"]],"inference/flip","inference/extract",[["exports"]],"inference/record",["module"],"meta/serialize",[{"source":"/Blik_2023_interface.js","scale":0.8,"gutter":840}],"script","script/index"]{background:transparent;max-width:90%;margin:auto;border-radius:.5em; border:2px dashed #616161}#[[0],{"inference/tether":["script/fold"]}]
or use you client's commands to invoke them sequentially if it also supports composition:
( node ./Blik_2023_interface.js ./Blik_2023_interface.js access "module.ts" | xargs -0text \
node ./Blik_2023_interface.js ./Blik_2023_meta.js parse $text "typescript" | xargs -0syntax\
node ./Blik_2023_interface.js ./Blik_2023_meta.js serialize $syntax "astring" | xargs -0text\
node ./Blik_2023_interface.js ./Blik_2023_interface.js access "module.ts" $text;
)#div{display:block;width:90%;margin:0px 5%;border-radius:.5em;border:1px solid #43a047;background:black;overflow:scroll;white-space:pre;font-family:monospace;color:#616161}
The standardize#b command can call this with a provided format for every staged module, before each commit if used in a pre-commit script (or explicitly by a future commit#b command):
( cp *git_hook_pre-commit.sh .git/hooks/pre-commit;
)#div{display:block;width:90%;margin:0px 5%;border-radius:.5em;border:1px solid #43a047;background:black;overflow:scroll;white-space:pre;font-family:monospace;color:#616161}
Copy the post-commit hook as well to re-apply your original formatting stashed by pre-commit after each commit:
( cp *git_hook_post-commit.sh .git/hooks/post-commit;
)#div{display:block;width:90%;margin:0px 5%;border-radius:.5em;border:1px solid #43a047;background:black;overflow:scroll;white-space:pre;font-family:monospace;color:#616161}
standardize#[["/Blik_2026_git.js/module/namespace"],"interface/fetch","interface/digest",[["standardize","apply"]],"inference/flip","inference/extract",[["exports"]],"inference/record",["module"],"meta/serialize",[{"source":"/Blik_2026_git.js","scale":0.8,"gutter":31}],"script","script/index"]{background:transparent;max-width:90%;margin:auto;border-radius:.5em; border:2px dashed #616161}#[[0],{"inference/tether":["script/fold"]}]
Further, to apply a preferred formatting to merged changes, the author#b command can be used in a post-checkout script:
( cp *git_hook_post-checkout.sh .git/hooks/post-checkout;
)#div{display:block;width:90%;margin:0px 5%;border-radius:.5em;border:1px solid #43a047;background:black;overflow:scroll;white-space:pre;font-family:monospace;color:#616161}
location#[["/Blik_2026_git.js/module/namespace"],"interface/fetch","interface/digest",[["author"]],"inference/flip","inference/extract",[["exports"]],"inference/record",["module"],"meta/serialize",[{"source":"/Blik_2026_git.js","scale":0.8,"gutter":31}],"script","script/index"]{background:transparent;max-width:90%;margin:auto;border-radius:.5em; border:2px dashed #616161}#[[0],{"inference/tether":["script/fold"]}]