Cool! First, no need to tag me, I already receive all the emails from this repository (you can set this up in the “admin” page of your repository, under the “permissions” tab).
First, I’d like to share the latest and greatest version of Pijul, as I managed to split up the giant TxnT
and MutTxnT
, in order to make all that a little clearer. I completed that step yesterday, but then was stupid enough to decide to also upgrade Sanakirja to version 0.15 in libpijul. Since Sanakirja 0.15 checks CRCs on almost all reads, and most lines in libpijul read from Sanakirja, that’s a massive change.
The way remotes are handled in libpijul is a bit unsatisfactory at the moment. Here are the constraints (I understand they aren’t obvious, please ask again if something is unclear):
We want a cache of the state of a remote, so that we can find out the latest changes in reasonable time, even on massive repositories. At the moment this is done in O(d + log n), where n is the number of changes in the remote, and d the size of the difference, which I think is optimal.
The Sanakirja backend is common to all platforms, and is a “fragile” binary format, in the sense that it can’t really be extended in crazy ways. For example, one can have a little over 500 different “root” tables (where each table is a B tree, or could be another datastructure in the future). Of course, more tables can be added and referenced from other tables, but this requires an extra query, which might involve more disk reads. In order to minimise that for common use cases, “standard” tables are stored as root tables. This is why the “remotes” table needs to be defined in libpijul: if it were defined as an “extension”, this could lead to a confusion in table numbers, which in turn could cause pristine corruption.
We also want to compile libpijul for weird platforms such as WASM, which can’t really implement the network protocol (or maybe using websocket, even if I don’t quite see how that could be useful). For that reason, the protocol is in Pijul at the moment, but maybe it should deserve its own independent crate, and libpijul could define a “standard” registry of extensions, where if someone writes an extension, the extension must somehow be made “official” in order to get an universal root number and avoid pristine corruption.
So in other words libpijul wants a stable identifier for remotes.
For the greatest stability, an ID field can be added to the config for each remote. It would then be set (and generated) when a remote that lacks an ID is pushed or pulled from. Or cloned, when a repo is first cloned. It would be best to have the ID generating function be part of libpijul so it can ensure it is unique from existing remote IDs. The down side would be it is possible for users to mess things up.
Or it the pull URL could be explicitly given as an ID, it would make the back end portion of remotes work better as the same state information would be used for both push and pulls.
.
SXEYMYF7P4RZMZ46WPL4IZUTSQ2ATBWYZX7QNVMS3SGOYXYOHAGQC
M3VTIZCPE7CMJXRENE7J3DYEXA4KILMNYLPMPCDRCWXTJ34JKSCQC
IMCZFTIJ245E3JBOHAY3FMEZCGTL4VNIF26WAKJSZMQXZJ4NK3LAC
HYRH4E55TIRBB3RFFR432METJPNVBSPL6DJVHXE5XGFGZAGBACDAC
5HF7C67M4DZMYTCIG32XEQQ662AHQMIHTHUK7TAVSO52XLMFBZPAC
OAXTXEAFX6YLO2XX6L4VMCVW4YZSIXWL6QOZKQCDSL7M44QNX66AC
UZZQ3VIA4YVL7C6P22LBPWWPB4BKH6VQLYKVHGQ3XRFISKM52TRQC
VN6L65VRWLKTIXY7XD7OOZBMNKNSIEJG6PJUX5NKKYVYGVG4DFTAC
2GNO2PLCZ3BM5RRRSPLGVWEWHOOTVT4VKFBNNQMUKOKF3VXL3ZFQC
3S4DR77ZU3XFGGDE6XSCUK6TN76IXNOQIKQSLDBM7KUHNILWHS3QC
AN7IDX26RK33ZXASXLJMD4GTFWHCTHMJ6Y5C4ROCPIH33VUT2EYQC
BAUL3WR2ACY2HCJIM7K6HJOJ3UXDJISGLMDCSPH3WMPGJPL5AR4QC
76PCXGML77EZWTRI5E6KHLVRAFTJ2AB5YRN5EKOYNAPKTWY2KCGAC
CVAT6LN3SYYLREM6NLM4IUPFI5EX3BL6MRPFTY24ROJFSB3J5OOQC
GUNVHCG3GTVBGGODDAHVZ5W552BS2IQEOKMAFGFNRTCZR6EPYWJAC
2KURKIFC6P62HW2TCV3N7IMCAARI7UBHYR5M3RIGWYLZU3X763AQC
IXGIROWKSRQM2E5Q7OVB7ZHGY5I5NSHI2WOOPLEHRKACNE3QH2JAC
XWETQ4DE4KL2GQWSEBE5NENLTSLIDF7RIWOCCVWJFQOVQJE5P33AC
IXWN5CYPMGNBRYKS2MMRV6DVAUQFSYUB2MXZLEMPF6RSEG5AFA6QC
JWTT77WJIGJOZVLLZBADUDZIMSEAR7ZLYLWISOXFJJCNWJGJPWQQC
OUWD436ATBTZJR53B6XDSI5SXRRNZV7YGRUEA5ACHZC2RUDP7G5QC
PJ7T2VFLV5PYG3CV23GC2GIQETXKGC6CO74JBGREV3JC3LG5OXUAC
UCQD3JDHULGTUSKWPD3I4FQHA2DX37X7MMHRCOPGQVOT65JWWCIQC
L4JXJHWXYNCL4QGJXNKKTOKKTAXKKXBJUUY7HFZGEUZ5A2V5H34QC
KYUXB7DZYVPGK3TZ5WSPRK33ZZLBWB73A2J3CF6VVJCB7XOSUW6QC
UBCBQ5FGH2KASHEUPDLIKGLVVX3GSRQ4F4P2JEJZL2NX2DUSYARAC
L5PHFTIERPDAFIOSHZSMAN2CUSFM626ISMGTDYRN5KWPLXCOVPXAC
YAJAXIV5VL263Z6FYLKFPROB3MQPRPH22P44GRGRVGEP56HOMBOAC
AXVPNZ2NVKYRCTKYI77H72CALZBRTHY3OK4CMWGMTSU2NPMOS42QC
NLGQAH4H35XC5XTH26BRXVFWGPPAMA4MDN3MHMGCOYE6ZZQMQ4AAC
YACC5QR6WTVC3IJCCVH6GUYFU4KAPITOED43V2MDP3TVGLTL2NEQC
7UPL3Y2A5QOBU6VIUHNWEFGSGQ5CMWGDGOVLRZ53UARXG3TDGLMAC
74HX2XZDHFRE7FIQ6LQZALIIKED2ABSGGBQ34ULYZ5ZBKK7UTHQQC
Q7CAYX5N2GFOGMZL3VXVWORMAPWEOECXE22BLXK7Q4WEPS4CE2SAC
GJNJ75U5ADCWNMLPBRM4FMYV6KJ366YLN5C7PWPZX3C5CWE5HZZQC
VZL5OHF5IQN3ORMBBZB7YSCI3VTSN5ZPZEQNLWUHBIE4EGNJ5COQC
VQPAUKBQ2POZKL7CZFAZK5ZQKEBYL27XZYZWYUSH5AH25KK6DWKAC
NX5I5H53IWX76GA3MTXTWZXU2HKUDL4ENED7LTGHMPWLHSAHYEAQC
YDKNUL6B4EFM5U2GG36SSEKXHS6XK4OLIWUVE4BUAJ5VYJFHAOIQC
UNZXTNSJI4YRY3EQ3M4HMBKQDNYDTY6B7IZRBNYGDJXTA2UKYWRAC
M5FK3ABTKBDG6HHW32G7UKRJEJQKD2U7BPXNZ3HVHBKULWVV6CTQC
Q4SVMHAEZQQCBFGPJMWS5H4VXB2HFQREZ3AWGOHFWHLFARUQVPBAC
TZVUNELWO5SIK7FKUTAR3ORAV2YYDFJ3EO7CTUOBDX4TXZOL5L3AC
YS2HLPX6S3FCPI3Q7TVFP3XIZPK4JRKV6PFWRNZHCWWC2P2SDDLQC
ISQJRA3OJJRDMYVQX7XNYGJNMR6CPWIVAIFOS2NCIZH2ZAPDTC5QC
RR65HCKOJU45UCNU5X3XM5HSIRHVUZU4IO4HEBQYHS22HYIIWITQC
UDHP4ZVBQZT2VBURB2MDCU2IZDNMCAFSIUKWRBDQ5BWMFKSN2LYQC
VMPAOJS2ZFOLNXALHWSVM5AFENWX6ZUACB45EJV3HXI7DQNAZPHQC
GLMOA3PFDR7HHJ3QMVZBNNJ3CGZAF72AZ5UBNEQON37K5WFNZP6QC
B5Z4IMEUYAEJPOU5EIAXI7VYZVUM6CWKV7CTSOXK3F4GXTNNMMAAC
23LVKATNTT74YKHG7KJM6SBO2IVZEV24TQ46ZJIHQ2IXONWNVXJAC
GURIBVW66JDQK3SJZRGVJ2MQLMT7JD4KLI5QPQZGPAL7WH3T6T4AC
RPZK3JQAOB3LSEFZFLCYFDVYLRX547FFSN5FWUTTB6JATROL4CTAC
3WIQYEISUMGOL5FY4LCWOJS55CTTQA7WMJZXAE3Q4GQUTBFLAE7QC
FBXYP7QM7SG6P2JDJVQPPCRKJE3GVYXNQ5GVV4GRDUNG6Q4ZRDJQC
VIHXB7SGRETFPHPYZFSRGOFRXEO4RZY57WDZSU6IAUEJRU3HPKQAC
I52XSRUH5RVHQBFWVMAQPTUSPAJ4KNVID2RMI3UGCVKFLYUO6WZAC
43AJ37IXON6PMMYRZM6OB2MJXPYCNIWW2XBDVNBXIRH5DD7JDTVQC
JG3MWHENOL4DM7DZU7CZA5UJQZDRRDEJTNZU7A74C4H3N6YNTJDAC
QE64ATLZWMKHYABCD3VA547PYXCK6YN3K7RE2TX3SCQNKG7XLVAQC
JRSBH6HTYXSIZKHW6SGWAF3JCEPMFTUG4JZUSUSF73ODEGFLAAJAC
ERV3644QELKOHAVNMZGRWYCPPN3XELTAH4PPFR6QKGWW73XBOOKQC
L4LAD4XMVJZIZGOA4TTFZETDAHNONEPYBYENTTCHMOYCWCV5B4XQC
WI5BS6BSRA7T3BCDF6EGB2JZHTZRX4SLT5EG4D67PVRBTZH5YIXAC
BXD3IQYNMKMI5BTANCF6NZHZP4CKPWADGJMBT2R3WTMKVKONT5QAC
N35L72XV5OWBWMEZBKZIKK5K6RMUYQOKGQEQ62N5NJ5N3UCHHWYQC
OCBM7IFE7CL3PM5KPYTRTKTHYKC76NTFK5C4VA4JFAKQUA6GC7FAC
H62VFFJEBL2I3O4D3BAJZ57ROPWUISC7JCDIWFBC5DAYJRHMMDXAC
JMBGCWM5FYXPAMTU5R7UCMBIHJMUVCT44B6KGQ7P7XZRX662TC4QC
AEPEFS7O3YT7CRRFYQVJWUXUUSRGJ6K6XZQVK62B6N74UXOIFWYAC
4H2XTVJ2BNXDNHQ3RQTMOG3I4NRGZT7JDLC2GRINS56TIYTYTO4QC
KWAMD2KR5UYRHHPZWL7GY2KQKNXNVS4BYBVK3FXDI23NQMWA3U4QC
GBLM3JLRCNEZLICNLV6M26YCZ4EYDG2F5BJOBH4FIBOM4W473LYAC
SEWGHUHQEEBJR7UPG3PSU7DSM376R43QEYENAZK325W46DCFMXKAC
KVBLRDOUFRYB6BPOQJDD7OVBYMTTPDAUX7CJ5DC3U7WFRI5OLWRAC
O4DNWMPDUWI6SKYOZTQKCSX6MSR73CTGCUSM65TSQYVOUSAAS6KAC
VLPIKNFSMJXOG37QYRGUJC6YFMZXZUFDADQV4PYASKKDQOJ24MZAC
Q45QHPO4HDTEZF2W4UDZSYYQ46BPEIWSW4GJILZR5HTJNLKXJABQC
MMUFJPXTN4CBS7ZXOJF3L3KV3ZCKN2ULBDSUS72XUIVC7RJZRB2AC
MF3WAHBIH6Q2F7ZOKWPEJF6VGSKJITWLR3Z64GTD6YQZNA5EATWQC
7PM25EXLNQ6JUUIZNTAOQYNNIZNG6TJREEBUSAIC3FIOE7FHETSAC
WZYPQBYNIUDLMMCQCVVFF7W2LE4UC3PZ2MIIRPEPHZPDWCXSDZOQC
367UBQ6KNAKUEWG32R4QRJ6H7IE7NAZFOPTC3ZOE4Z6E44RV3ISQC
K6GWUOD55G377RVEEMMRPZ4EUAHCM2BGXNRJTE5UZJFFMJGFCEZQC
PCEJFKFXAFGYGHMM4BOBGFV3WRFXEBF2UQYQHLJ7MURRYBKRM3EAC
RJMQSZER3DDPF7ANVKDPMR3KZZ7DKM5ASAOVPBQBAPDLJNL6BJ5AC
7L32EXDWOT2BWHPC3ZPAE4W6BOGQTTJUYJWTNMLS6INFXZ7GLPNQC
WXAFKN6JL3LRIRTTW2Q7UQIZBZSAHYIUVTPWKMK2GK2W3GZ44XHAC
NV6OSWDHKDVMX7V24S5MZ4SOIHC3JW4CP7PD2AYKQBXIKVRZKVYAC
BQDE4VH6OZHULHAOP37GSBJMCI5QIFSOU6COBYKPAY6FPH3IMISAC
62XVBWPYCBULZ2IUWF36JVHAPMKCGQC53PQQ53AAGZGC2KT7VQRQC
SNZ3OAMCPUGFYON5SZHQQQK46ZZMVMJECJYEUCMG657UVLY2PNBQC
SFY4U6XENPS67BWNMTZI472WBORGVL7B4FZDIHGHEJQR5VYRYCVAC
UTDZKZGPHLL2MK5FFP6ANYCX2PZYTKXIQ2RNWBG2WGDJNVYLLWLQC
J63VVQ5IQS6MCLK5WAU4OFPBOAVRCLAPLYW6RCZ7NFV4QYPYV6NQC
L5IUD2DSLEK4SYPF6PLNO7C3TZEFYFHNM42HGEHY5VWW5MHD7CXAC
5DVRL6MFXQOCPOZMYSKBERMRRVUTYRL2SRGRTU2MH4IEOFCDKM3QC
R3H7D42UZ446V5TO2574BMAQQAYYJPEIMSZVDPAGVIYU2COJSWBAC
5BRU2RRWOQBMS2V3RQM7PRFR5UILYZ73GISHAKJA6KIZGC5M2MFAC
33ANCTMFGDEI4CDYZCDERYDSWLL2UVXUVAX3GA75RY5VZWYMQSLQC
VXZNQQHCDC6MBLUMNDJVPM4I7XWTDYBPZZNCPZCA6EJ3GS5WAQGQC
HXEIH4UQ6EX3MAY33JK4WQUE5GUSZ673OX57JKNFXC2N2QLTXKXAC
BJOZ25EUUCRNS5K4RVPA6Z7C2QEQXZOJDIQR2PGQZQ5ZV544OVQQC
FMKKWCFVK5CPPP55T4VMCHSFPZ47EBK6V7D4MJ5BH55TP4UBOZXAC
2K7JLB4Z7BS5VFNWD4DO3MKYU7VNPA5MTVHVSDI3FQZ5ICM6XM6QC
SAGSYAPXQ2T6GC3B3TNRPNFTZMS7UMME6YQGSF5MOIM66S5NKB2QC
WLUID7NANDWTN5GOECNEKFTLZF3MUVS7K26YWLYLSGJ56G63NV4QC
SE4RJYBZBNU6I3URBUMWP6T27CGGXLBEWWDB7WWX3W3AYSU6AFAAC
WIORLB47KYY5ZDKSAQEQ5NV2J3F3RIO5FVGD6LGF73FD5LWJLUAAC
7RAQWUMUFSNZATLDLDRRS5ZLSVF7EZDS67B35B7WPAONFW4FF23AC
6GI4CC6JW46FLT4437EZL3HFGWUO4QUCMQDIGDAKFZWJIGBIYO6QC
SZWBLWZ4LUJZHTSYOIGJMXM7KPCGWJFPKLHYA5MHY7UTPNLZV5KQC
QWD7UE766WLJ3JZU7L2UXMV7Q236DSDMH2CCI4M6HIA4QA3QVFAQC
BT2ZHPY4LTECZDNPNLX5IUAEA6CYB4RRBGVBXUNK3ARHMWQK7KHAC
KD4JIMAE6M2LFWEHFPEL4RTRV7UWYWNGGS52N2TKQ42ZNFSNLCEQC
NGSZJPOB2OVJ6BGCC5BWQUWAXHXIFWCENI4ULBGIEEUWQBHG7J6QC
GVQ7YSEDDCYYYWDJ5JUVFSBWA5EZVOZJI63KK6E46N6Y2B6LP72AC
IUGP6ZGBFLDRAKJOHFQNG67LZBDXUJ4QM25GOY3QT6GER3NVTHXQC
TCGBEQ3IB4BVKQFCPNEYNN72OP67RCXOIRQGLBWOG2BTUS7DLPSQC
QYY37T6YMICHA57GBXBBR4OYE2A76SFDKXPDKIKSEDDXCNQVC5CAC
OXMYGLW2563T6VA75532P7N7CZBHVJL4VI5CQBJ6X4MOX4RKL4GAC
V2MDXX622MAXHXGLX7ERVKGYZVZDCYJIFET3TGGIK455XIADYJUAC
JP3BYVXXWFBVQ23MEHJ3LE36AN26P6OCZALKUXMNLHS2TSTM3NKAC
3YDPHBANMNSK7Z5SCG745VLTP4BBQWIXCJTQOSDI6UJGYR6S45EQC
DNQHXWRZF6EWII3RGQ6HPGFD47BOOFH4FCQHSCACBS3RLQO3DNIQC
KDF6FJRVF72L274BEUJCTUKRFMNL6BDZMTVKDPEYGFX4TC3YOVSQC
H23LO7U7MNB5GTLOUIFYAJ6DP57DM3VFBR4IBOAVPMHS356AYFPQC
ZXTHL45OYLOICXTXXEQ6AMNSLMQFZ6BFUJWMO6LZOSDK7ERROC5AC
BZSC7VMYSFRXDHDDAMCDR6X67FN5VWIBOSE76BQLX7OCVOJFUA3AC
WZVCLZKY34KQBQU6YBGJLQCDADBQ67LQVDNRVCMQVY3O3C3EIWSQC
6T5ULULMRGU5GJ3JQTEH2QFQN5IMP53TYFFXUT5UE6FA6WWFFMFAC
MWKDNWZWM45YH7JJ6ZUQGIOLME4QOPVDWMRGDYPOCCUYDF4ZPKNAC
4OCC6D42GZYRDLH3NSKXMJTRKXP7UZ6Z3YNGCNUT7NT6WBDBCBIAC
7A2TSC4PAKK3WOH3DMAJASCEC6D5JLJWNFWJTEEBE4CVS4K76PPQC
WKX5S4Z4DOB5S6A6X5V6ECZFCHQUMWRGX5XT4FBOG57P6HPWK7CAC
FYVZZNRQ4ZCJN7EJ7LRN4A6TYTWUG4YHRVMD4KAFYJALEBLZOBDQC
KTTKF3RWYAK2YSH2DYYW5QVG4KSNGWUBJBFHKE24OJ7LFCBF5FEAC
G6YZ7U65AW42M4RSWPXOCJH62XZ5OKVGOQ2UEB6SBNKNJEWYBAEQC
QNJBR73KCSCCF6FTHGZDF2K7PZQL3EFKZFOBT77KYZBMALTTW6OQC
VO5OQW4W2656DIYYRNZ3PO7TQ4JOKQ3GVWE5ALUTYVMX3WMXJOYQC
737IBW6O6CVVA6K3RT2UO226CUXLURC5KSJUVAGDJHZCDERB7GUAC
BUM5P4VGVYYQPKF4EWFH5SVRLTMGB4GMIPDZFLLPQTFD7MCSGXUAC
PH7B6I3U5XCACAX6VX3ZDJD2DQOQS7725R6CTOATNC26NP4VPUFQC
7T5STZYBIUN5AQPFKASNYO24QFLNBX3YCE4YIIXEQNJYR5LSZ6EQC
KQTD46KVVWMJ3W6O55BEJLCVTNTDLUH6QT46AEFT7OU2SELXG4IAC
A7NTQINQCT6GSJZIBPWM6KD2HYGV4XBSV7FWLFYY4YKLSEOW57KQC
HMMMKONLCRAXVT7SO2ITTFDOJIQKKVSRIZPXYVPDC34RCBHWMHVAC
BD5PC25AB5MKVIYDFSDGRZ4YGX4PKW4SMZ3YAYAPNA5HLDVJUR3QC
5QTMRUXNE2XNJCMLN6MQN24UEZ55EFC3LIR4PO6OPNTT5KEL7WXQC
JACZWIJ6UEL5HWZRNOOXTFXUEG67XJDPC5D72LYUPCVVJ6WB7JQAC
EZ7VRNRLL7L7I54BPYG4Y4PR7VRFAQXPVHCHDB3MQI3IYAQEKXEAC
7FFFKQZU3TFXWL45TILYNX5A7AC7HBK526SD5DZGYCELN76YE7TAC
QAPSKSFCALRNAAC52S4N7BSCLTFL2UMSNFVXRA447M2VMXE4KVLQC
BBKV6VMN4EVBCBSAQMTL2TARBBSQEZGRCXMTKYUIDOJ3HZISUP7AC
JSSEYW7NUUB5S2T6GPXOHECHZ5JY3KG3AT2IPSWCVIPUDHOBNZQAC
UTEVDVGBBJZWMPQIM3NSSVN2GNBMY6I6FTAVXER7NMVBQSYKAVBAC
KJDQ2WOMIUTVDEEQ7NMJYBZAVUZ3NIVOVJ6MUCZPRAWIEWOV6TWQC
X6YFD4WVMUYJCR5IYPJH6UKYVWSA7DKBRVJ6XQFXHOE2TRYUTAHAC
XL6Y64UPFLIVRV3YVJMTTMZU7VL6SUXVE6BKL6K7DYRKVJ4X727AC
OP77HLKNGBOHKHNGITIL4U6FAFUNZRPORJRCFXOJJE5DI5WO5S4QC
A6R6SGCPLFM45QNWJLISFBR3EEXVITYHCWEUOPNH4UIGIWJRTZAQC
3M7WBE24JTPTHWQOU5PO2ZJYKPKEH2F6R4M6RWIRFG334PQEA55QC
ATZ3BWSEFJBLVGDUZFESRNHVCIO6ZRZ3ALPANZSVGVO7A5BUAFQQC
XAY4DYRRPDEQY7XUWJ3OWSXPCEPZ6VFQ6273JPLE3FEGJQAGV6YQC
VDI66F2DYNFGXAMBHLMTKHCMEER3NM52P5PTNZQEEEAT4EZBHT5QC
IM6UFPOZHZTBMESRXGBALOAWJWUUDGLP2TVLSZ3RZPSJITKB3R7QC
65S67T3EKKLFRBCU73Z542V7A4JSMGP37OJINON6N563UIBQAITAC
PSKXR4QEPPVJZR777HW67IEHUPGZB44MFCNQ2KUS422Q3W22IQWAC
73NW2X2MI767RYNTKS67ZB5QUWYEAA4SCORLD52K36ZU3JAK67AQC
OJZWJUF2TCGZ7RFVY6FPKBS5P3C4BGHZDPVH775OHVNVFMJICKNQC
BE7GUCI2N6TX3P2HRMFSH7XLJKILDPOKOXKA7HWOABBFNKCKMZLAC
FE5ES6Q46FMWYPNNNJLORY377QGDE57LBBDIVWDTC6Z7U4U73NEQC
6WFOU7UXCYM5UWA5WVZ72XFRJWJA5GWCIAC5PI5NOEFHNFD3VKNAC
SPA2OL5ITFMLB5P2WL342QAU2FXPKSFS4XHAMW6HYWOGSGLO2MJAC
H3NAKE2I2KPGXMKXOYKV23SXSIWFWBEXQJDI2XANONK54NVYPD4QC
ZHABNS3S6FSINO74FOI5KHYXYDTBPO4FQTTYTUS7NNKEVVNLYC4AC
6RVT5X4LTRP5XHVDESXMIC2DHMT5MUQ24ZDWEBJ4XYTF6LJXK7CAC
IYJZVLETBAQDDELENH3FX7ZTOC3HY4UJ3AMC3MACW6O7ZCWZTR6AC
FXT5FS5WIDBA3HPTJRFGRGULZIGAWAJXT2U6RFYGDLO2PYDG4VEAC
NZIK34IMY3L5YMFISBLHUL5ATENBL35VOZJW4EHPINZEL6IQE4UQC
ZTVNGFNTYSZKPNWG7PGXTWVXKUM4KL2NKEUSMCUQYLCE4CYA6RVQC
4VWXL6KQGYGDUQRCVJCEVIV6CKJSEIYDX4YF33OX6EDNKJNEGD2AC
XTMYHJZLWWT5I2PJAL7PCNA3V6LL6C45WOZG7THFLIC736AQYDUQC
SLJ3OHD4F6GJGZ3SV2D7DMR3PXYHPSI64X77KZ3RJ24EGEX6ZNQAC
MU5GSJAW65PEG3BRYUKZ7O37BPHW3MOX3S5E2RFOXKGUOJEEDQ5AC
YX3VCEOM36NOK6757SD4SZX4FHB7FBAVRKFJH2QFPCYILC4SBRNAC
NA5I4WYNE2O3LPSHXGWXW7XL4YNYFDREEGDOP6LJ5HJXTQDXM7BAC
R6LAMLHWDNMHPBUS6GVMUKG7HX66XN3IN7MROLT5ST52QXCXU2FQC
5YDI33C4QRHATA6H3HHMBYFOBLAMXLLHWSDGJAH57DR6AMWO7AAQC
PESRJZBOH6PQSDPJ7SDJX52O65FMPEV4373YYEWZSF7ATXDQL2VAC
Y7YAFMFFJY3SQ3GYN3SS4V3FZWMH3B5L65AXQBXOR5XARSMF5JJQC
UFCZKKLXVYQYQBYENCAFHY3ZPPSDAJJAIREZSYNQM4QNXV6G6RXAC
IQ4FCHPZYGTZHCQHUIRCMUI5LCHIDSJCM2AZXGRJARWLCPPLXZOQC
ZXCRG5RPZU7DKPFI24IRLHV4DZSB6NJKA73J6FC7ARXT2KGOIV7QC
6DOXSHWGKJIMIPFCNLASGKBAJCJMJULW5HFRZAZ67EYSMXXGJ3KAC
2MWJ2H6CQVPV2M2HOYOI4EHEK37E4EKLNQISGFUYVH2KCTAJQDCQC
CFNFIUJVWV2PHHZKAPBY6GLW4TCX2N66DYH2QCFU5X7D7KE5D4AQC
6YMDOZIB5LVYLFIDGN2WNT5JTHEAMS4TFPVDEZ3OWXWOKJOC5QDAC
VBMXB443FGZL6DLT6KAP2ICFCCQNXCUMDEUL67HB4CNKFMBBNSSAC
BVVMTOYWG4WSVWEYNW2XIG3D34Y7V54ACSSJPQ2AREOO7NGPMLDQC
WTZXEWY7IAXJAFNV7STCNQY2SNRDPHX3MKOEZ77NEJUN4MS2VYSQC
LNVEFL32BYPYBKLKJHQ7GVLY2KUMORWBAA6XVP2Y5C33PURROMFAC
Apparently, forgetting to specify main in the push command line when pushing from a channel not named main does bad things. They still seem to have ended up in main:243
, but it was unable to recognize that the changes already existed as it thought it was pushing to a channel named after my local channel.
So, here are the details on the changes (2MWJ2H6CQVPV2M2HOYOI4EHEK37E4EKLNQISGFUYVH2KCTAJQDCQC is the main change set, LNVEFL32BYPYBKLKJHQ7GVLY2KUMORWBAA6XVP2Y5C33PURROMFAC fixes conflict with the latest changes in the Nest at the time):
.pijul/config
now has a url
and an optional pushurl
field for remotes as mentioned in the original post.pijul clone
has a new flag --remote <name>
. When provided, a remote for the source repository will be created called <name>
. This remote will be set as the default remote.pijul push
and pijul pull
both have a new --remote
flag. When present, the to
or from
arg will be interpreted as the name of a remote in .pijul/config
rather than a path or URL. If to
or from
is omitted, the default remote is used.pijul push
and pijul pull
in the case that to
or from
is omitted and the --remote
flag is not present, then it is assumed that it is a push / pull between local channels in the repository..pijul/config
, the url
value is used as the ‘name’ rather than the pushurl
. Thus when the URLs for pushing and pulling are different, for libpijul
should see it as the same remote making the state tracking more efficient. I am not sure if everything at the later steps is hooked up, but the name
field of the different remote types is being set to the correct name.I have done some testing and the changes appear to be working correctly.
As a note, the archive command has a --remote
flag that does not refer to the remotes from ‘.pijul/config’, but rather it is for a path or URL. It might need to be changed to avoid confusion.
Thanks! I’ll try to fix that soon. The issue is that Pijul assumes you’re pushing to a channel named the same as your local channel. I believe the expected behaviour here is that the Nest tells you the channel doesn’t exist, rather than saying it does, and has no change.
Well, it’s more my mistake than yours, so I’ll pick the right ones, don’t bother removing any of them ;-)
Also, pulling from this discussions gives me just the changes I don’t already have.
I just found time to review these changes.
I like the idea of pushing and pulling to different addresses (even though the SSH protocol is likely to always be faster, because it’s done as a single request that doesn’t need to re-handshake each time), but I believe the previous solution for push and pull was better, where --remote
was automatic when the name was present in .pijul/config.toml
.
I believe Git and Darcs users expect pijul push remote_name
to work without needing to add --remote
. Would you mind changing your patches to do that? Alternatively, you could split it up into smaller parts.
Another comment I have is, while you’re at it, it would be nice to have a “default channel” option. The way to use the Nest’s CI at the moment is to push to channel_name/ci
: for example, I push changes to Pijul to main/ci
, and having an automatic way of doing this would be cool.
Thanks again!
On note needing --remote
flag, I suppose the question is if it is possible for remote names to collide with valid path names (say on the local file system)? If that is the case, then a flag would be needed to make it not check if the target is the name of a remote. I would also be adding a --self
flag to push / pull between channels inside the repository.
For default channels on a remote, wouldn’t it be better to have a default remote channel set per local channel rather than a blanket default?
Alright, I’m super sorry about this, it seems I got overwhelmed with the extraordinarily large number of discussions. Too many things have changed since you opened this discussion, including a datacentre fire :(
However, I like the idea, and have decided to implement it with the new system, see #ZSFJT4SFIAS7WBODRZOFKKG4SVYBC5PC6XY75WYN7CCQ3SMV7IUQC.
I have been working on a changes to improve how
pijul
handles remotes.Currently, remotes are just a list of paths and URL stored in the repository’s config file, with one being a default. Only the default is particularly useful to the user as it will be used when a remote is not provided to the
push
andpull
commands. The others can only be listed to the console with thepijul remote
command.My changes have remotes have a human friendly name that they can be referenced by when running
push
andpull
commands. Furthermore, they can have different URLs (or paths) for pushing and pulling. The allows pulling over HTTP(S) and pushing over SSH while using the same name.The pull URL is required while the push URL is optional. Therefore the pull URL field is
url
while the push URL ispushurl
. If only a pull URL is provided, it will be used for both pushing and pulling.The changes should be finished up sometime tomorrow. I am putting this up in advance to see if anyone has comments on the subject.
@pmeunier
I am tagging you as it seems
libpijul
touches on remotes to some extent. It gets their ‘name’ from the repository’s config. Currently the ‘name’ of a remote is its URL / path. My changes would make the ‘name’ be a human friendly name. Is there anything you can think of that might cause issues as a result?Also, currently the default remote is stored in the
default_remote
field of the config file and is not listed again with the other remotes. I will need to change it so the default does not get picked up twice. If you could tell me wherelibpijul
gets the list of remotes from the config, it would be helpful.