Skip to content

Port git to Plan 9 #305

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Port git to Plan 9 #305

wants to merge 3 commits into from

Conversation

lufia
Copy link

@lufia lufia commented Aug 3, 2019

Changes from v1

  • Use gmake
  • Use sh
  • Remove dependencies to Plan 9 tools; rc and mk

What I did

I ported git, and git subcommands with gmake to Plan 9.
This pull request contains patches for existing codes, and new files to build git in Plan 9.

I added three new options into Makefile.

  • USER_GITCONFIG - default ~/.gitconfig
  • USER_GITCREDENTIALS - default ~/.git-credentials
  • USER_GITCREDENTIAL_CACHE - default ~/.git-credential-cache
  • USE_EXEC_WRAPPER - default empty

In Plan 9, user configuration files are stored at $home/lib, instead of dotfiles.
http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html

And Plan 9 haven't hard link and symbolic link. Thus I added exec-wrapper to want to shrink disk usage.
http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames

Installation

# ANSI/POSIX commands are installed at /bin only in current namespace.
% bind -a /bin/ape /bin

# Plan 9 C compiler can't initialize struct fields that is bit field so remove bit fields from all C files.
% ./remove-bitfields.sh

# build Git toolchain with /n/sources/contrib/andrey/make-3.81.tgz
% gmake 'prefix=' 'gitexecdir=bin/git-core' 'sysconfdir=sys/lib/git' 'template_dir=sys/lib/git/templates' install

@gitgitgadget
Copy link

gitgitgadget bot commented Aug 3, 2019

Welcome to GitGitGadget

Hi @lufia, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that this Pull Request has a good description, as it will be used as cover letter.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

  • the lines should not exceed 76 columns,
  • the first line should be like a header and typically start with a prefix like "tests:" or "commit:", and
  • the commit messages' body should be describing the "why?" of the change.
  • Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a PR comment of the form /allow <username>.

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions.

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox ("raw") file corresponding to the mail you want to reply to from the Git mailing list. If you use GMail, you can upload that raw mbox file via:

curl -g --user "<EMailAddress>:<Password>" --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

@lufia
Copy link
Author

lufia commented Aug 3, 2019

/allow lufia

It is noisy, sorry.

@gitgitgadget
Copy link

gitgitgadget bot commented Aug 3, 2019

Error: User lufia is not permitted to use GitGitGadget

@dscho
Copy link
Member

dscho commented Aug 3, 2019

/allow lufia

@gitgitgadget
Copy link

gitgitgadget bot commented Aug 3, 2019

User lufia is now allowed to use GitGitGadget.

@lufia
Copy link
Author

lufia commented Aug 3, 2019

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Aug 3, 2019

Submitted as pull.305.git.gitgitgadget@gmail.com

@gitgitgadget
Copy link

gitgitgadget bot commented Aug 4, 2019

On the Git mailing list, "brian m. carlson" wrote (reply to this):


--cVp8NMj01v+Em8Se
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2019-08-03 at 23:52:08, KADOTA, Kyohei via GitGitGadget wrote:
> I ported git, and git subcommands only written in C to Plan 9. This pull
> request contains patches for existing codes, and new files to build git in
> Plan 9.
>=20
> All build options such as NO_PERL are not supported yet, and also some git
> subcommands written not in C is not available yet. But git can synchronize
> to remote repository with git pull and git push via HTTPS.
>=20
> This pull request don't contain a part of Git toolchain for example
> git-credential-store, etc. So I'm going to port other parts of Git toolch=
ain
> too in the future.

This series seems to build a whole new build system that uses Plan 9
tools. Typically the way ports to non-POSIX platforms (such as Windows)
have been handled is that the Unix tools, including GNU make, have been
ported to those platforms, and the POSIX (or POSIX-ish) environment used
there.

I'm concerned that by introducing a whole bunch of new, Plan 9-specific
build code, we're going to have it fall behind with features or bug
fixes, because none of the main developers test on Plan 9, and most
contributors will not have the Plan 9 skills or systems to maintain the
code.

In addition, the editor used by git commit and other commands invokes
"sh", but you've set this to "rc". That's completely different from the
way that all other environments work, and it means that Git on Plan 9
operates in a totally different, incompatible way there. We also use a
POSIX shell for the testsuite, and we rely on it quite heavily. rc is
not going to cut it there.

Plan 9 has a POSIX environment, and I think it might be a better idea to
require that as a condition for building and running Git. It will likely
be a lot easier, at least.
--=20
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

--cVp8NMj01v+Em8Se
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.17 (GNU/Linux)

iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAl1GKPgACgkQv1NdgR9S
9oubCw//Yx45/jOjzOlY1d7uPf1xhLoAm6gEcYD23X799GewNWKYJfAvWOJUX/4Q
8aWWgvcqyI+haQxNb9LTeeJIVnBTaW9NfjoLMFP1Cc7tDMMAyg2vOukaWjq517G9
6iM66aq3ZbeeZhXG078JPj83/1qs9Rs4uVRiPXgjN1WTk3cPE1fREFOmNEh23ldA
dUE2ij57uVfb6t1NNiCMUEqofTnSODsC7alZdUhlc4I8dp8pnK1o4JOitnQFGOD3
LlYNzsO0Gt9/+NosWWE7m70l6GkbYPIw6RYgpBn4Ehmf+6ut2fqsb3JcgsiS54F6
NCLwUK3g1PZeQypcm9vnNMZ78bljsl1oqAEfOeeXSsx6L9lCASWAqgUylsftw7RS
0h9V2co75ro5choSSezMod0TV+zIB0qKv4S7SswYXLmMp3X+VDySc/iC7Dn33/bq
Vqhh7oTKt+C+7p57chKFoovdKKFnP0k2o66VUv55UDZEosO8iKgL7CcRdDPkNOST
xSw3trAOQBRFWlbwKOiUx0cslA2rq1CSyYEFeBNNd3cBELnZ9ah+Wtqsy3wqtQwT
atbkIY9nJkgieqa2ggQKLMBzkKj5ovaXH6HAwCc0/HWOAj6D5mIZ5Tml71Ldwdum
ZV6aV1BidhX89SOZXls8RcSNEgCqEUG1k5m6OL3y8QJpoUQDYz4=
=/4Uy
-----END PGP SIGNATURE-----

--cVp8NMj01v+Em8Se--

@gitgitgadget
Copy link

gitgitgadget bot commented Aug 4, 2019

On the Git mailing list, Kyohei Kadota wrote (reply to this):

2019-08-04(Sun) 9:38 brian m. carlson <sandals@crustytoothpaste.net>:
>
> On 2019-08-03 at 23:52:08, KADOTA, Kyohei via GitGitGadget wrote:
> > I ported git, and git subcommands only written in C to Plan 9. This pull
> > request contains patches for existing codes, and new files to build git in
> > Plan 9.
> >
> > All build options such as NO_PERL are not supported yet, and also some git
> > subcommands written not in C is not available yet. But git can synchronize
> > to remote repository with git pull and git push via HTTPS.
> >
> > This pull request don't contain a part of Git toolchain for example
> > git-credential-store, etc. So I'm going to port other parts of Git toolchain
> > too in the future.
>
> This series seems to build a whole new build system that uses Plan 9
> tools. Typically the way ports to non-POSIX platforms (such as Windows)
> have been handled is that the Unix tools, including GNU make, have been
> ported to those platforms, and the POSIX (or POSIX-ish) environment used
> there.
>
> I'm concerned that by introducing a whole bunch of new, Plan 9-specific
> build code, we're going to have it fall behind with features or bug
> fixes, because none of the main developers test on Plan 9, and most
> contributors will not have the Plan 9 skills or systems to maintain the
> code.
>
> In addition, the editor used by git commit and other commands invokes
> "sh", but you've set this to "rc". That's completely different from the
> way that all other environments work, and it means that Git on Plan 9
> operates in a totally different, incompatible way there. We also use a
> POSIX shell for the testsuite, and we rely on it quite heavily. rc is
> not going to cut it there.
>
> Plan 9 has a POSIX environment, and I think it might be a better idea to
> require that as a condition for building and running Git. It will likely
> be a lot easier, at least.
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

I think it is possible to replace rc with ape/sh, ape/sh is POSIX
shell in Plan 9.

However Plan 9 don't have recent versions of Unix tools,
such as gcc, g++, autotools, gmake or perl,
so it is VERY hard to use Makefile instead of mkfile.

@gitgitgadget
Copy link

gitgitgadget bot commented Aug 4, 2019

On the Git mailing list, Jonathan Nieder wrote (reply to this):

Hi,

Kyohei Kadota wrote:

> I think it is possible to replace rc with ape/sh, ape/sh is POSIX
> shell in Plan 9.
>
> However Plan 9 don't have recent versions of Unix tools,
> such as gcc, g++, autotools, gmake or perl,
> so it is VERY hard to use Makefile instead of mkfile.

The default Git build doesn't use autotools.  See INSTALL for more
details.

What version of gmake is available for Plan 9?  I wouldn't expect
Git's build system to be super demanding as far as recent "make"
features go.

So I wonder whether it would make sense to do something like the
following:

- add entries to config.mak.uname to set the compiler e.g. to 6c
  when appropriate

- make appropriate compatibility fixes in git-compat-util.h

- add any necessary helpers to the compat/ directory

- use gmake to build

Would that work?

Thanks,
Jonathan

@@ -26,7 +26,7 @@ else
VN="$DEF_VER"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

"lufia via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: lufia <lufia@lufia.org>
>
> Plan 9 don't have expr(1).
>
> Signed-off-by: lufia <lufia@lufia.org>
> ---
>  GIT-VERSION-GEN | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
> index a0766f64ed..754d4486f5 100755
> --- a/GIT-VERSION-GEN
> +++ b/GIT-VERSION-GEN
> @@ -26,7 +26,7 @@ else
>  	VN="$DEF_VER"
>  fi
>  
> -VN=$(expr "$VN" : v*'\(.*\)')
> +VN=$(echo "$VN" | sed 's/^v*//')

The expr utility is often a shell built-in, but sed is almost never
(as it is a lot more heavy-weight command).  It may not be a bad
idea to get rid of expr with a simple shell parameter expansion,
e.g.

	VN=${VN#v}

instead.

The original explicitly is prepared to see no 'v' at the beginning
(in which case it just passes VN intact), or more than one 'v's (in
which case all leading 'v's are stripped), while the shell parameter
expansion strips zero or one 'v' at the beginning.  So there is a
slight "regression" there, but I do not think it matters (certainly,
it was *NOT* my intention while writing the original to strip two or
more 'v's).  181129d2 ("For release tarballs, include the proper
version", 2006-01-09) snuck in the "all leading 'v's are stripped"
without sufficient explanation, but I do not think it was an attempt
to allow two or more 'v's.

@dscho
Copy link
Member

dscho commented Aug 21, 2019

Seems that something breaks the Windows build ☹️

@lufia lufia force-pushed the plan9 branch 3 times, most recently from e3a4dc5 to 055c340 Compare August 24, 2019 04:06
@lufia lufia changed the title Port git to Plan 9 Port git to Plan 9 (v2) Aug 27, 2019
@lufia lufia changed the title Port git to Plan 9 (v2) Port git to Plan 9 Aug 27, 2019
@lufia
Copy link
Author

lufia commented Aug 27, 2019

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Aug 27, 2019

Submitted as pull.305.v2.git.gitgitgadget@gmail.com

lufia added 3 commits May 31, 2020 21:51
In Plan 9, almost environment variables are not capitalized.

Signed-off-by: lufia <lufia@lufia.org>
Signed-off-by: lufia <lufia@lufia.org>
Plan 9 ANSI/POSIX environment is:
* No expr(1)
* sed(1) limits max length of label to 7 characters
* pcc ignores object files that has incorrect extension,
  so should use underlying loader directly.
* No ln(1). Instead use bind(1), but bind isn't persisted to the disk.
  However it isn't efficient to copy git to git subcommands such as git-add.
  Therefore Plan 9 needs exec-wrapper to switch behavior by executable name.
* tar(1) don't have -o option

Signed-off-by: lufia <lufia@lufia.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants