-
Notifications
You must be signed in to change notification settings - Fork 143
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
base: master
Are you sure you want to change the base?
Port git to Plan 9 #305
Conversation
Welcome to GitGitGadgetHi @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:
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 patchesBefore 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 Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment 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 |
It is noisy, sorry. |
Error: User lufia is not permitted to use GitGitGadget |
/allow lufia |
User lufia is now allowed to use GitGitGadget. |
/submit |
Submitted as pull.305.git.gitgitgadget@gmail.com |
On the Git mailing list, "brian m. carlson" wrote (reply to this):
|
On the Git mailing list, Kyohei Kadota wrote (reply to this):
|
On the Git mailing list, Jonathan Nieder wrote (reply to this):
|
@@ -26,7 +26,7 @@ else | |||
VN="$DEF_VER" |
There was a problem hiding this comment.
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.
fcd27f0
to
b45f70c
Compare
Seems that something breaks the Windows build |
e3a4dc5
to
055c340
Compare
/submit |
Submitted as pull.305.v2.git.gitgitgadget@gmail.com |
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>
Changes from v1
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.
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