[9fans] Getting git9 -- moved to github.
I realized that a few people were still running the hg repo. It's buggy and no longer maintained (and now, gone). Git9 is self-hosting on github now. To bootstrap git9: hget https://github.com/oridb/git9/archive/master.tar.gz > git9-master.tar.gz tar xzf git9-master.tar.gz cd git9-master mk install If you want to get the bugfixes and new features that will eventually show up (commit grafting, https clone, stable ids on git/import, ...): git/clone git://github.com/oridb/git9 cd git9 mk install And then update occasionally with git/pull && mk install -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M0db6b269806533ffe3282ac2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
π Π²Ρ, 19 ΡΠ½Π². 2020 Π³. Π² 20:04, : > I realized that a few people were still running the hg repo. > It's buggy and no longer maintained (and now, gone). Git9 is > self-hosting on github now. > > To bootstrap git9: > > hget https://github.com/oridb/git9/archive/master.tar.gz > > git9-master.tar.gz > tar xzf git9-master.tar.gz > cd git9-master > mk install > > If you want to get the bugfixes and new features > that will eventually show up (commit grafting, > https clone, stable ids on git/import, ...): > > git/clone git://github.com/oridb/git9 > cd git9 > mk install > > And then update occasionally with > > git/pull && mk install > -- Π‘ Π½Π°ΠΈΠ»ΡΡΡΠΈΠΌΠΈ ΠΏΠΎΠΆΠ΅Π»Π°Π½ΠΈΡΠΌΠΈ ΠΠΈΠ»ΠΊΠΈΠ½ Π‘Π΅ΡΠ³Π΅ΠΉ With best regards Zhilkin Sergey -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M703091162ae7a8a6fa7d4cb6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
I made some changes to git9/proto.c that seem to handle git/fetch git+ssh://g...@git.ff.co.za:23456/waspa/console.git successfully. What is the procedure to submit such (small) changes for inclusion? (I also needed to add the port recognition code to 9front's /sys/src/cmd/ssh.c to interpret the host:port combination, but that is a separate issue and I'll have to ask elsewhere about that.) Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M215eab7cf89548785bc1af0d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> git/fetch git+ssh://g...@git.ff.co.za:23456/waspa/console.git The port can be specified natively through the dialstring technology: git/fetch git+ssh://git@net!git.ff.co.za!23456/waspa/console.git It may be useful to add support to git9 for translating :port notation to a dialstring; there's no need to change ssh.c. > What is the procedure to submit such (small) changes for inclusion? Attaching a patch to your mail here or directly to Ori will work. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M6f02d4b1f022b1761014b99f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
On 2/2/20, k...@a-b.xyz wrote: >> git/fetch git+ssh://g...@git.ff.co.za:23456/waspa/console.git > > The port can be specified natively through the dialstring technology: > > git/fetch git+ssh://git@net!git.ff.co.za!23456/waspa/console.git > > It may be useful to add support to git9 for translating :port notation > to a dialstring; there's no need to change ssh.c. > Given that I could not find a -p option for ssh and I seldom use Plan 9 networking off the beaten path, so the "net!host!port" did not come to mind, the hour it took to modify the ssh.c code seemed well spent. I'm sure other will find it familiar, even in the user@host:port format. No reason to swim against that stream. That is, in support of the ssh change. Also surprisingly small and non-invasive. Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M69d746c256b5ef06f5585d0c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
user@host:port is not a valid syntax in openssh, and neither in plan9. user@host syntax is certainly useful, but i think that's already there. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M7848f339a3ca7fc8d5dfb072 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> user@host:port is not a valid syntax in openssh, and neither in plan9. it has to be handled by the code that parses the *URL* and converts it into ssh arguments with a dialstring. ssh does not know anything about URL's. > user@host syntax is certainly useful, but i think that's already there. correct. by using netmkaddr() so proto and port are optional. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M1f9edac6b1b687291a00932d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> I made some changes to git9/proto.c that seem to handle > > git/fetch git+ssh://g...@git.ff.co.za:23456/waspa/console.git > > successfully. What is the procedure to submit such (small) changes for > inclusion? Put the code in an email. Ideally to this list so we can get more eyeballs looking over it. Put the patch into the body of the email instead of attaching, for easier review and commenting. The output of 'git/diff' should be sufficient for applying with ape/patch. Also, if you're changing the URL parsing, take a look at this: https://raw.githubusercontent.com/git/git/master/Documentation/urls.txt If we make changes, it would be worth fixing compatibility so that you can just paste in any git url. (Note that we don't yet have local repositories: That would require a git/serve command) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M18ce498b4d5ffb2e0a4ba75c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> (I also needed to add the port recognition code to 9front's > /sys/src/cmd/ssh.c to interpret the host:port combination, but that is > a separate issue and I'll have to ask elsewhere about that.) ssh, like most plan 9 programs, supports net!host!port syntax. It making ssh gratuitously different is a bad idea. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M5c56de982b657099c162e421 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
On 2/3/20, o...@eigenstate.org wrote: > > ssh, like most plan 9 programs, supports net!host!port syntax. > It making ssh gratuitously different is a bad idea. > I beg to differ. It is optionally and compatibly different and pretty much something the SSH maintainers clearly also think should NOT be added from traditional reasons. How long did it take before "-l lucio proxima,alt.za" became "lu...@proxima.alt.za" and who had the influence to make that happen? >From "lu...@proxima.alt.za" to "lu...@proxima.alt.za:4321" seems a pretty natural, intuitive step. I may of course be missing an incompatibility but, failing that, I think I have a valid case. Looking at 9legacy's ssh/(ssh1 ssh2) may say otherwise and that I'm willing to concede. But a "-p 4321" option and its equivalent seems to me to require just a couple of additional lines in the ssh(1) man page to be worth accepting. I confess I have not yet looked at that man page, so the scope may need to be bigger. But I will include my take on that in the SSH patch (which is forthcoming according to the advice above, separately from the git9 one, just not yet). As for git9/proto.c, I merely re-arranged the code, mostly. Something about a trailing colon was in place, but I did not entirely understand what it attempted to take care of. I still need to check that I have not broken "git fetch" in the process. Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M11f612987edb79e86fc058c0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> Looking at 9legacy's ssh/(ssh1 ssh2) may say otherwise and that I'm > willing to concede. But a "-p 4321" option and its equivalent seems to > me to require just a couple of additional lines in the ssh(1) man page > to be worth accepting. Do you intend to make this syntax work consistently across all of plan 9? > As for git9/proto.c, I merely re-arranged the code, mostly. Something > about a trailing colon was in place, but I did not entirely understand > what it attempted to take care of This is a valid repository syntax: git+ssh://u...@host.com:path/to/repository -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M5b5262a7154071ebe4b6ed56 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
On 2/3/20, o...@eigenstate.org wrote: > > Do you intend to make this syntax work consistently across all of plan 9? > Only 9front SSH, because it begs to be available. Legacy SSH is different (or I'm missing a big chunk of patching and I'll never really get there, I don't think). >> As for git9/proto.c, I merely re-arranged the code, mostly. Something >> about a trailing colon was in place, but I did not entirely understand >> what it attempted to take care of > > This is a valid repository syntax: > > git+ssh://u...@host.com:path/to/repository > Git can be obscure: the leading / in the "path" shouldn't be optional. Yet git+ssh://u...@host.com:port/path/to/repository is also valid (or at minimum, works) with "/path" treated as local to the user's $HOME (ssh landing directory). Or am I getting that wrong? But Unix "scp" has a similar "flaw", except you are compelled to use the -P (note the case inconsistency) option to provide a non-standard port, so the leading slash would then pin the "/path" to "/". I guess I need to brush up on the standards around URLs? -- Lucio De Re 2 Piet Retief St Kestell (Eastern Free State) 9860 South Africa Ph.: +27 71 471 3694 Cell: +27 83 251 5824 -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-Mfbfff1fddb3014c5cf5bdccc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
i agree. the scp -P vs. ssh -p inconsistency is a good reminder showing why the host:port or host!port syntax is more useful. since plan9 is different we already have host!port, changing one program to host:port without changing all the others does not seem consistent to me. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M2cb1ab41afcf9ac0435b1a4e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
On 2/3/20, hiro <23h...@gmail.com> wrote: > > since plan9 is different we already have host!port, changing one > program to host:port without changing all the others does not seem > consistent to me. > I can't argue with that point, except that the ! notation had escaped me altogether, whereas the : notation is very familiar. The reason I won't offer to make an effort towards a general approach is that I'm not sure we won't come up against potential snags or conflicts. If one can be sure that the risk does not exist, then a single network address parsing function becomes a possibility. Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M1a4df9fb4d12ac7015cf9a80 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
we have to decide every time when we interoperate inferior systems where to draw the border, how much we want to imitate and how much is better hidden when it doesn't fit. in this corner-case thankfully the decision is trivial. git is full of other much more icky weirdness and i'm quite astonished how diligently ori_b is handling this :) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-Mc052f7a2a9a527543871a85d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
On 2/3/20, hiro <23h...@gmail.com> wrote: > we have to decide every time when we interoperate inferior systems > where to draw the border, how much we want to imitate and how much is > better hidden when it doesn't fit. > in this corner-case thankfully the decision is trivial. > git is full of other much more icky weirdness and i'm quite astonished > how diligently ori_b is handling this :) > I am in total agreement, Ori is clearly committed to getting Git working more than adequately. Not having the stomach to do that myself, I want to support him as far as possible. But where I only partially agree is where Plan 9 concepts contradict what may be "common practice". A URL is a well defined object and adopting it as a standard, as quite a few services have done (I'm thinking PostgreSQL and OpenLDAP, for example) rather than pursue the '!' convention seems worth it. But, as you suggest, one does have to draw the line. Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M9c04b7ccc0f49966b4a423da Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> But where I only partially agree is where Plan 9 concepts contradict > what may be "common practice". A URL is a well defined object and > adopting it as a standard, as quite a few services have done (I'm > thinking PostgreSQL and OpenLDAP, for example) rather than pursue the > '!' convention seems worth it. Yes. git9 takes URLs. This is why I posted a link to the spec that we should follow. I will take patches that bring us in compliance with https://raw.githubusercontent.com/git/git/master/Documentation/urls.txt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M7a6698b405c29b6ede1b51df Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> But where I only partially agree is where Plan 9 concepts contradict > what may be "common practice". A URL is a well defined object and > adopting it as a standard, as quite a few services have done (I'm > thinking PostgreSQL and OpenLDAP, for example) rather than pursue the > '!' convention seems worth it. i find plan9 dialstrings much easier to deal with than urls that have all kinds of escapes and encodings depending on which part in the url stuff appears in. they carry alot of baggage arround. urls might appear in ASCII context, then you need to punicode the domain name if it happens to contain non-ascii characters while plan9 dial strings are guaranteed to work consistently. the resolution process is done by ndb/cs and it can accept unicode just fine. plus picking the "!" as a separator works with ipv6 while using ":" needs v6 literal escapes like: [2001:1:2:3:4::]:22 this was a huge mistake. in plan9 we are lucky not to be affected by this too much and we can handle these things without much pain and without touching every program. dialstrings also let you pick the protocol and also the ip stack to use. programs that do not accept dialstrings sabotage a usefull plan9 capability and break consistency. i'm pretty sure the original plan9 ssh1/ssh2 also accept dial strings just fine. thats just like, my opinion, man. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M48e08819ec859259f6714dcf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
On 2/3/20, cinap_len...@felloff.net wrote: > this was a huge mistake. in plan9 we are lucky not to > be affected by this too much and we can handle these > things without much pain and without touching every > program. > I am not challenging the lucky break Bell Labs got with the use of exclamation marks, although the use of Bash (an unfortunate shell if ever there was only one!) makes you regret that decision. And if you ever work in support, someone else's configuration of Bash is seldom something you can escape from. > dialstrings also let you pick the protocol and also the > ip stack to use. programs that do not accept dialstrings > sabotage a usefull plan9 capability and break consistency. > It is a wonderful thing for a Plan 9 user to be able to ignore the reality of Linux desktops, as much as it is wonderful for Linux users to be spared the Windows World. But I wonder how many of the people here live in that reality? > i'm pretty sure the original plan9 ssh1/ssh2 also accept > dial strings just fine. > And so it should, may it rest in peace. As I said, I am not challenging the Plan 9 lucky break at all. As far as 9front cmd/ssh.c goes and Ori's git9/proto.c goes, both worlds seem to coexist happily, just as the two workstations coexist on my desk. There is an ambiguity in git9, I need to examine it in more detail. If somebody can show that I have broken something irreparably, I take it all back, if not, what we need is a little bit of additional information in the man pages. I haven't had the time to organise any of that, unfortunately. Hopefully, over the next weekend I shall. Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M52db17ffd60dd915ab0db7fa Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
On 2/3/20, o...@eigenstate.org wrote: > > Yes. git9 takes URLs. This is why I posted a link to the spec that we > should follow. I will take patches that bring us in compliance with > https://raw.githubusercontent.com/git/git/master/Documentation/urls.txt > I must have missed that the first time, I will look into that as soon as possible. It is perhaps unfortunate that I now have a working solution for my own problem (contextual as it is), so less pressure to produce a more general answer; I do by nature seek general solutions, rather than narrow, short term ones. I'll try to post the patches here by coming Monday morning. Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-Mf1060a76e8d89388be01cafd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
I guessed my way around the p9p lib9p and libthread facilities and squeezed some degree of p9p portability into a recent version of Ori's git9. It can be found, warts and all: github.com/lootch/git9 My aim was to operate across platforms on a single version of Git, one with the Plan 9 philosophy behind it (I am deeply thankful to Ori for creating the foundations for that). Sadly, besides all the likely mistakes I have no doubt made in my limited comprehension of multithreading, I definitely could not find sufficient prior art to model serving the gitfs synthetic filesystem outside of the p9p environment (announce it on net!*!git, say). It does rather seem that the necessary thread/9p functions were not ported to p9p. I am aware that the modified version is not likely to even compile in the Plan 9 environment, I will attend to that soon. If anyone is at all interested in this kind of convergence and can guide further efforts on my part, I would gladly accept their suggestions. Not much to be gained by pointing out to me that this exercise is wasteful. I have a bee in my bonnet about ridding Linux of its Posix legacy and moving to a p9p-friendly environment. Lucio. > On 2/3/20, o...@eigenstate.org wrote: >> >> Yes. git9 takes URLs. This is why I posted a link to the spec that we >> should follow. I will take patches that bring us in compliance with >> https://raw.githubusercontent.com/git/git/master/Documentation/urls.txt PS: I didn't keep that promise, did I? I replied to Ori's mail at the time, but now I am surprised to discover what it was all about. I suspect old age is playing tricks on my memory. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M33808e421c99249bf77972cd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
