Getting git9 -- moved to github.

Getting git9 -- moved to github.

[ori]

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

Re: [9fans] Getting git9 -- moved to github.

[Sergey Zhilkin]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

👍

вс, 19 янв. 2020 г. в 20:04, <ori@eigenstate.org>:

> 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
>


-- 
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey

[-- Attachment #2: Type: text/html, Size: 1986 bytes --]

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

I made some changes to git9/proto.c that seem to handle

     git/fetch git+ssh://git@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.

Re: [9fans] Getting git9 -- moved to github.

[kvik]

> git/fetch git+ssh://git@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.

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

On 2/2/20, kvik@a-b.xyz <kvik@a-b.xyz> wrote:
>> git/fetch git+ssh://git@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.

Re: [9fans] Getting git9 -- moved to github.

[hiro]

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.

Re: [9fans] Getting git9 -- moved to github.

[cinap_lenrek]

> 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

Re: [9fans] Getting git9 -- moved to github.

[ori]

> I made some changes to git9/proto.c that seem to handle
> 
>      git/fetch git+ssh://git@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)

Re: [9fans] Getting git9 -- moved to github.

[ori]

> (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.

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

On 2/3/20, ori@eigenstate.org <ori@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 "lucio@proxima.alt.za" and who had the
influence to make that happen?

From "lucio@proxima.alt.za" to "lucio@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.

Re: [9fans] Getting git9 -- moved to github.

[ori]

> 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://user@host.com:path/to/repository

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

On 2/3/20, ori@eigenstate.org <ori@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://user@host.com:path/to/repository
>
Git can be obscure: the leading / in the "path" shouldn't be optional. Yet

	git+ssh://user@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

Re: [9fans] Getting git9 -- moved to github.

[hiro]

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.

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

On 2/3/20, hiro <23hiro@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.

Re: [9fans] Getting git9 -- moved to github.

[hiro]

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 :)

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

On 2/3/20, hiro <23hiro@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.

Re: [9fans] Getting git9 -- moved to github.

[ori]

> 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

Re: [9fans] Getting git9 -- moved to github.

[cinap_lenrek]

> 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

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

On 2/3/20, cinap_lenrek@felloff.net <cinap_lenrek@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.

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

On 2/3/20, ori@eigenstate.org <ori@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.

Re: [9fans] Getting git9 -- moved to github.

[Lucio De Re]

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, ori@eigenstate.org <ori@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.