- Loading...
...
Code Block | ||
---|---|---|
| ||
$ git config --global core.editor "vim" |
...
Code Block | ||
---|---|---|
| ||
$ git config --global aliashttp.<name>proxy '<command>' |
For example, if you want to type git co
instead of git checkout
you would run:
PROXY-HOSTNAME:PROXY-PORT' |
Substitute PROXY-HOSTNAME
with the hostname of the HTTP(S) proxy server, and PROXY-PORT
with the port of the HTTP(S) proxy server. When using the credential manager on Windows, the proxy must be specified scheme first (e.g. http://).
Code Block | ||
---|---|---|
| ||
Code Block | ||
| ||
$ git config --global alias.co<name> 'checkout<command>' |
For example, if you want to type git co
instead of git checkout
you would run:
Code Block | ||
---|---|---|
| ||
$ git config --global alias.co 'checkout' |
Glad you asked! Please see the Aliases page.
...
If you are using Git version 2.24 or newer you can also use the command: git switch --create <NAME-OF-BRANCH>
Code Block |
---|
$ git branch -D <NAME-OF-BRANCH> |
...
If you are using the Skara CLI tools then and have the branch you want to publish currently checked out, then you can just run the command git publish
...
...
...
Code Block |
---|
$ git push --delete origin <NAME-OF-BRANCH> |
Note: the above command assumes that the branch exists in the remote repository that origin is referring to.
Code Block |
---|
First ensure that you have configured your full name, email and editor. You must then add the files that you want to be part of the commit (even files that are already tracked by Git):
Code Block | ||
---|---|---|
| ||
$ git add path/to/file1 path/to/file/2 |
You can inspect the changes that will be part of the commit by running the following command:
Code Block | language | bash
---|
$ git diffmerge <OTHER--staged |
You can then create the commit by running the following command:
Code Block | ||
---|---|---|
| ||
$ git commit |
The above command will open your editor where you willl the commit message. If the commit message only is a single line then you can pass it directly to commit command: git commit -m 'Your commit message'
.
BRANCH> |
Code Block |
---|
$ git log --graph --pretty=oneline --first-parent --abbrev-commit master..HEAD |
First ensure that you have configured your full name, email and editor. You must then add the files that you want to be part of the commit (even files that are already tracked by Git):
Code Block | ||
---|---|---|
| ||
$ git show <COMMIT> |
Yes, but you will be mutating history. If you have already pushed the commit, then other people might depend on the commit you are about to mutate. If you have only pushed the commit to your personal fork and you are not currently collaborating with someone, then it is fine to mutate the history (you yourself are the only one who will be affected). If you have pushed the commit to a project repository, then it is not fine to mutate history, since you cause problem for other contributors.
In many cases, for example when working on a pull request, you can just make an additional commit and push it. The Skara integrate command will squash (collapse) the commits in the pull request into a single commit before integrating it, so the final result will be as if you only had made one commit.
If you still want to mutate history and update the last commit, first add the files you want to add to the commit:
Code Block | ||
---|---|---|
| ||
$ git add path/to/file1 path/to/file2 |
Then run the following command to amend the HEAD
commit:
Code Block | ||
---|---|---|
| ||
$ git commit --amend --no-edit |
Go to https://github.com/settings/tokens and and click on "Generate new token"
A personal fork is a copy of another repository with one major difference:
...
add path/to/file1 path/to/file/2 |
You can inspect the changes that will be part of the commit by running the following command:
Code Block | ||
---|---|---|
| ||
$ git diff --staged |
You can then create the commit by running the following command:
Code Block | ||
---|---|---|
| ||
$ git commit |
The above command will open your editor where you willl the commit message. If the commit message only is a single line then you can pass it directly to commit command: git commit -m 'Your commit message'
.
Code Block | ||
---|---|---|
| ||
$ git show <COMMIT> |
Yes, but you will be mutating history. If you have already pushed the commit, then other people might depend on the commit you are about to mutate. If you have only pushed the commit to your personal fork and you are not currently collaborating with someone, then it is fine to mutate the history (you yourself are the only one who will be affected). If you have pushed the commit to a project repository, then it is not fine to mutate history, since you cause problem for other contributors.
In many cases, for example when working on a pull request, you can just make an additional commit and push it. The Skara integrate command will squash (collapse) the commits in the pull request into a single commit before integrating it, so the final result will be as if you only had made one commit. If you mutate history in an active pull request, it will make it much harder for reviewers to follow the changes.
If you still want to mutate history and update the last commit, first add the files you want to add to the commit:
Code Block | ||
---|---|---|
| ||
$ git add path/to/file1 path/to/file2 |
Then run the following command to amend the HEAD
commit:
Code Block | ||
---|---|---|
| ||
$ git commit --amend --no-edit |
Go to https://github.com/settings/tokens and and click on "Generate new token"
...
...
...
github/adding-a-new-ssh-key-to-your-github-account
A personal fork is a copy of another repository with one major difference:
...
A pull request is a way to suggest that some changes from a personal fork should be incorporated into the original repository the personal fork was created from. Reviewers can comment upon and need to approve a pull request before it can be integrated. The concept of a pull request is very similar to OpenJDK's concept of "RFR" emails - both are used to suggest changes and offer a way for reviewers to provide feedback on the suggested changes.
...
emails - both are used to suggest changes and offer a way for reviewers to provide feedback on the suggested changes.
A draft pull request is a pull request that is not yet ready for review. Draft pull requests are primarily used to share work in a early stage or run additional testing before declaring the pull request ready.
--draft
flag to gh pr create.
--draft
to flag to git pr create
.git pr set --no-draft.
git pr set --title='New title'.
...
A draft The body, or description, of a pull request is a the initial comment in the pull request that is not yet ready for review. Draft pull requests are primarily used to share work in a early stage or run additional testing before declaring the pull request ready. Can be compared to the body of the initial "RFR" email.
...
...
--draft
flag to gh pr create.
press the three little dots in the top-right corner of the initial comment and select "Edit":--draft
to flag to git pr create
.git pr set --no-draft.
git pr set --title='New title'.
The body, or description, of a pull request is the initial comment in the pull request. Can be compared to the body of the initial "RFR" email.
...
git pr set --body.
To modify your patch in a pull request, just push more changes to the branch the pull request is based on. Avoid modifying changes that are already part of the pull request branch or force pushing unrelated changes as that will mess up the pull request and make it hard for reviewers to make sense of it. When Skara integrates the pull request, all the changes will be squashed into a single change anyway.
If your pull request slips too far behind the target branch (e.g. the master branch in the mainline jdk repository), you will need to pull in changes from master and resolve any conflicts before you can integrate. When doing so, it's usually preferred to merge the changes rather than rebasing, especially if the reviews have already started on the pull request. If changes are rebased, the history in the pull request becomes problematic and hard to follow for reviewers. When Skara integrates the pull request, all the changes will be squashed into a single change anyway.
This depends on the project - some projects (typically those in a prototype phase) give project Committers direct push access, but most opt to use pull requests for contributions.
Yes, JDK Committers (and above) are allowed to push directly to the openjdk/jdk-sandbox repository. See the documentation for the how to name your branches to avoid conflicting with other Committers' branches
...
.
...
Code Block | ||
---|---|---|
| ||
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"t ed25519 -C github -f filename/for/the/private/key |
The public key will be stored next to the private key and have the same as the private key but will have the suffix .pub
.
Note: pick a strong password for your key. You will not have to type your password every time you want to use your SSH key if you use the SSH agent.
...
Yes, by adding a host alias for github.com in your SSH configuration file ~/.ssh/config
(C:\Program Files\Git\etc\ssh\ssh_config
on Windows). Add the following lines to ~/.ssh/config
the SSH configuration file:
Code Block | ||
---|---|---|
| ||
Host github.com github gh
User git
Port 22
Hostname github.com |
You can now clone from GitHub using the aliases listed after Host
:
Code Block | ||
---|---|---|
| ||
$ git clone github.com:openjdk/jdk $ git clone github:openjdk/jdk $ git clone gh:openjdk/jdk |
...
Yes, by adding a ProxyCommand
directive in your SSH configuration your SSH configuration file ~/.ssh/config
(C:\Program Files\Git\etc\ssh\ssh_config
on Windows). The value for ProxyCommand
is operating system dependent, since different programs are available on different operating systems. Please follow the instructions specific for your operating system below:
Add the following lines to ~/.ssh/config
. The value for ProxyCommand
is operating system dependent, since different programs are available on different operating systems. Please follow the instructions specific for your operating system below:
...
:
Code Block | ||
---|---|---|
| ||
Host github.com github gh
User git
Port 22
Hostname github.com
ProxyCommand nc -X connect --proxy PROXY-HOSTNAME:PROXY-PORT %h %p |
Substitute PROXY-HOSTNAME
with the hostname of the HTTP(S) proxy server, and PROXY-PORT
with the port of the HTTP(S) proxy server.
Add the following lines to ~/.ssh/config
:
Code Block | ||
---|---|---|
| ||
Host github.com github gh User git Port 22 Hostname github.com ProxyCommand /usr/bin/nc -X connect -proxyx PROXY-HOSTNAME:PROXY-PORT %h %p |
Substitute PROXY-HOSTNAME
with the hostname of the HTTP(S) proxy server, and PROXY-PORT
with the port of the HTTP(S) proxy server.
...
. Note that the full path to nc
must be used since Homebrew might install the GNU version of nc
(which does not support the -X
flag).
Add the following lines to ~/.ssh/C:\Program Files\Git\etc\ssh\ssh_config:
Code Block | ||
---|---|---|
| ||
Host github.com github gh User git Port 22 Hostname github.com ProxyCommand /usr/bin/nc -X connect -xC:\Program Files\Git\mingw64\bin\connect.exe -H PROXY-HOSTNAME:PROXY-PORTHOST %h %p |
Substitute PROXY-HOSTNAME
with the hostname of the HTTP(S) proxy server, and PROXY-PORT
with the port of the HTTP(S) proxy server. Note that the full path to nc
must be used since Homebrew might install the GNU version of nc
(which does not support the -X
flag).
...
program connect.exe
is part of Git for Windows, if you install Git via some other mechanism then you might have to install connect.exe
yourself.
...
Yes, see the plugin GitHub Pull Requests and Issues.