Difference between revisions of "WesnothRepository"

From The Battle for Wesnoth Wiki
m (Browse the code)
m (Update version numbers)
 
(32 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
{{Compiling Wesnoth}}
 
{{Compiling Wesnoth}}
  
The <cite>Battle for Wesnoth</cite> code-base is stored in a '''<dfn>version control repository</dfn>'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.
+
'''The <cite>Battle for Wesnoth</cite> code-base''' is stored in a '''<dfn>version control repository</dfn>'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.
  
 
When a release is planned, the current set of the files in the repository is ''"frozen"'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or "'''<dfn>repo</dfn>'''") version is by definition the most up-to-date version of the code.
 
When a release is planned, the current set of the files in the repository is ''"frozen"'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or "'''<dfn>repo</dfn>'''") version is by definition the most up-to-date version of the code.
  
The <cite>Wesnoth</cite> repository is a '''Git''' repository and is hosted on '''GitHub''': '''[https://github.com/wesnoth/wesnoth <https://github.com/wesnoth/wesnoth>]'''.
+
The <cite>Wesnoth</cite> repository is a '''Git''' repository and is hosted on '''GitHub''':
  
== Git ==
+
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}
  
Git is the most widely used open-source version-control system. You can learn more about it at its website: '''[https://git-scm.com <https://git-scm.com>]'''.
+
== What is <cite>Git</cite>? ==
 +
 
 +
{{SideBox|heading=Are you a newcomer to Git or GitHub who would like to work on <cite>Wesnoth</cite>?|If so, you may find iceiceice's <cite>[[Git for Wesnoth Crash Course]]</cite> to be a useful read -- while <cite>WesnothRepository</cite> is also beginner-focused, it's not as extensive as iceiceice's <cite>Crash Course</cite>).}}
 +
 
 +
<dfn>Git</dfn> is the most widely used open-source version-control system. You can learn more about it at its website:
 +
 
 +
{{FeaturedURL|https://git-scm.com}}
  
 
Git replaced '''Subversion (<dfn>SVN</dfn>)''' as <cite>Wesnoth</cite>'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (<dfn>CVS</dfn>)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.
 
Git replaced '''Subversion (<dfn>SVN</dfn>)''' as <cite>Wesnoth</cite>'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (<dfn>CVS</dfn>)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.
Line 15: Line 21:
 
== Browse the code ==
 
== Browse the code ==
  
There are currently two main streams of development ("<dfn>branches</dfn>"): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.
+
{{SideBox|heading=Want a {{abbr|GUI|Graphical User Interface}} for Git?|[https://www.syntevo.com/smartgit/ <cite>SmartGit</cite>] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ <cite>Qt Creator</cite>] and <cite>Microsoft Visual Studio</cite> provide Git GUIs. <em><strong>However</strong></em>, the official Git command-line program is <em>by far</em> the easiest Git program to get help with -- you may well have trouble finding people who can help you with a Git GUI.}}
  
You can use a Web browser to view the source code at: '''[https://github.com/wesnoth/wesnoth <https://github.com/wesnoth/wesnoth>]'''
+
You can use a Web browser to view the source code at the following Web address:
 +
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}
 +
 
 +
There are currently two main streams of development ("<dfn>branches</dfn>"): the '''master''' branch (1.19.x), and the '''stable''' branch (1.18.x). (1.16.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.
  
 
== Download ==
 
== Download ==
Line 23: Line 32:
 
To '''''clone''''' a copy of the repository into a directory named "''wesnoth''", run this command:
 
To '''''clone''''' a copy of the repository into a directory named "''wesnoth''", run this command:
  
  git clone "<nowiki>https://github.com/wesnoth/wesnoth.git</nowiki>" wesnoth
+
  '''>''' git clone "<nowiki>https://github.com/wesnoth/wesnoth.git</nowiki>" wesnoth
  
{{SideBox|style=font-size:.75em;line-height:1.6|There are other '''<dfn>transport protocols</dfn>''', in addition to '''Hypertext Transfer Protocol Secure (HTTPS)''', over which one can clone a Git repository from GitHub, including:
+
{{SideBox|style=font-size:.75em;line-height:1.6|heading=Technical aside: Git transport protocols|There are other '''<dfn>transport protocols</dfn>''', in addition to '''Hypertext Transfer Protocol Secure (<dfn>HTTPS</dfn>)''', over which one can clone a Git repository from GitHub, including:
  
* '''Secure Shell (SSH)''' ("<code><nowiki>ssh://git@github.com/wesnoth/wesnoth.git</nowiki></code>", or "<code>git@github.com:wesnoth/wesnoth.git</code>"), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the "Push access" section, below).
+
* '''Secure Shell (<dfn>SSH</dfn>)''' ("<code><nowiki>ssh://git@github.com/wesnoth/wesnoth.git</nowiki></code>", or "<code>git@github.com:wesnoth/wesnoth.git</code>"), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the "Push access" section, below).
* Git's '''native transport''' protocol ("<code><nowiki>git://github.com/wesnoth/wesnoth.git</nowiki></code>"), which <em>may</em> be somewhat faster than HTTPS (though GitHub uses a faster '''"smart" HTTPS''' transport), but is <strong>insecure</strong> and should be used (if one <em>must</em> use it) with caution (check the commit hashes!).
+
* Git's '''native transport''' protocol ("<code><nowiki>git://github.com/wesnoth/wesnoth.git</nowiki></code>"), which <em>may</em> be somewhat faster than HTTPS (though GitHub uses a faster '''"smart" HTTPS''' transport), but is <em><strong>insecure</strong></em> and should be used (if one <em>must</em> use it) with caution (<em>check the commit hashes!</em>).
  
 
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}
 
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}
 +
 +
<small style="font-size: 95%">('''Note:''' the "'''>'''" sigil represents a command prompt; '''don't type it in'''.)</small>
  
 
=== FAQ ===
 
=== FAQ ===
Line 48: Line 59:
 
The first command links your local repository to the upstream repository; the second <dfn>checks out</dfn> a <dfn>working tree</dfn> (i.e., copies the files out of the "''.git''" directory into a form that you can use).
 
The first command links your local repository to the upstream repository; the second <dfn>checks out</dfn> a <dfn>working tree</dfn> (i.e., copies the files out of the "''.git''" directory into a form that you can use).
  
 +
'''Alternative:''' This will make a shallow clone and allow you to fetch additional history as desired.
 +
# Start by using a clone command
 +
# Run a git fetch command with an increased depth, such as "git fetch --depth=2000"
 +
# Continue to run additional fetch commands, each time increasing the depth, based on what your connection can handle. As of this writing, the max depth is around 60-70K.
 +
# When an increase in depth no longer brings additional data, verify you have a complete repository by using "git fetch --unshallow"
 +
# To fix the single branch checkout aspect, use git config and fetch commands.
 +
A sample sequence is shown below. You may want to use smaller depth increases (i.e.,2-5K) based on your connection speed and reliability.
 +
'''>''' git clone --depth 1 "<nowiki>https://github.com/wesnoth/wesnoth.git</nowiki>" wesnoth
 +
'''>''' git fetch --depth=10000
 +
'''>''' git fetch --depth=20000
 +
'''>''' git fetch --depth=30000
 +
'''>''' git fetch --depth=40000
 +
'''>''' git fetch --depth=50000
 +
'''>''' git fetch --depth=60000
 +
'''>''' git fetch --depth=70000
 +
'''>''' git fetch --unshallow
 +
'''>''' git config remote.origin.fetch "<nowiki>+refs/heads/*:refs/remotes/origin/*</nowiki>"
 +
'''>''' git fetch origin
  
 
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''
 
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''
  
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named "''wesnoth-1.12-single-branch-test''":
+
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.18 branch, and store it in a directory named "''wesnoth-1.18-single-branch-test''":
  
  '''>''' git clone --branch 1.12 --single-branch --depth 1 "<nowiki>https://github.com/wesnoth/wesnoth.git</nowiki>" wesnoth-1.12-single-branch-test
+
  '''>''' git clone --branch 1.18 --single-branch --depth 1 "<nowiki>https://github.com/wesnoth/wesnoth.git</nowiki>" wesnoth-1.18-single-branch-test
  
 
Example results:
 
Example results:
  
  '''>''' git clone --branch 1.12 --single-branch --depth 1 "<nowiki>https://github.com/wesnoth/wesnoth.git</nowiki>" wesnoth-1.12-single-branch-test
+
  '''>''' git clone --branch 1.18 --single-branch --depth 1 "<nowiki>https://github.com/wesnoth/wesnoth.git</nowiki>" wesnoth-1.18-single-branch-test
  Cloning into 'wesnoth-1.12-single-branch-test'...
+
  Cloning into 'wesnoth-1.18-single-branch-test'...
  remote: Counting objects: 18725, done.
+
  remote: Counting objects: 20751, done.
  remote: Compressing objects: 100% (17541/17541), done.
+
  remote: Compressing objects: 100% (20087/20087), done.
  remote: Total 18725 (delta 1571), reused 7397 (delta 1004)
+
  remote: Total 20751 (delta 968), reused 11881 (delta 416), pack-reused 0
  Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.
+
  Receiving objects: 100% (20751/20751), 444.98 MiB | 636.00 KiB/s, done.
  Resolving deltas: 100% (1571/1571), done.
+
  Resolving deltas: 100% (968/968), done.
Checking connectivity... done.
+
  Checking out files: 100% (20369/20369), done.
  Checking out files: 100% (18593/18593), done.
+
  '''>''' du -sh wesnoth-1.18-single-branch-test ''# "du" means "disk usage".''
  '''>''' du -sh wesnoth-1.12-single-branch-test ''# "du" means "disk usage".''
+
  1.3G wesnoth-1.18-single-branch-test
  1.1G wesnoth-1.12-single-branch-test
 
  
 
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.
 
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.
Line 75: Line 103:
 
For '''<dfn>push access</dfn>''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.
 
For '''<dfn>push access</dfn>''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.
  
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:
+
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple macOS, at least) this:
  
  ssh-keygen -t rsa -b 15360 -f "<var><file></var>" -C "<var><your name></var>'s SSH key for GitHub"
+
  '''>''' ssh-keygen -t ed25519 -f "<var><file></var>" -C "<var><your name></var>'s SSH key for GitHub"
  
On a typical Linux distribution or on Apple OS X, <var><file></var> would be, e.g., "''~/.ssh/id-key-for-github''".
+
On a typical Linux distribution or on Apple macOS, <var><file></var> would be, e.g., "''~/.ssh/id-key-for-github''".
 
 
<strong>Note</strong> that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.
 
  
 
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally "''~/.ssh/config''"):
 
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally "''~/.ssh/config''"):
Line 92: Line 118:
 
Then, if you have not yet cloned the repository, clone it via SSH:
 
Then, if you have not yet cloned the repository, clone it via SSH:
  
  git clone "<nowiki>ssh://git@github.com/wesnoth/wesnoth.git</nowiki>" wesnoth
+
  '''>''' git clone "<nowiki>ssh://git@github.com/wesnoth/wesnoth.git</nowiki>" wesnoth
  
 
If you have already cloned the repository, you can set it to use SSH transfer:
 
If you have already cloned the repository, you can set it to use SSH transfer:
  
  git remote set-url origin "<nowiki>ssh://git@github.com/wesnoth/wesnoth.git</nowiki>"
+
  '''>''' git remote set-url origin "<nowiki>ssh://git@github.com/wesnoth/wesnoth.git</nowiki>"
 +
 
 +
You can also leave your local repo using the read-only URL, and add a '''pushurl'''. Manually editing the .git/config also allows it to be commented-out to avoid accidentally pushing to it instead of a fork:
 +
 
 +
<nowiki>
 +
[remote "origin"]
 +
url = https://github.com/wesnoth/wesnoth
 +
# pushurl = git@github.com:wesnoth/wesnoth.git
 +
fetch = +refs/heads/*:refs/remotes/origin/*</nowiki>
  
 
=== Force-pushing policy ===
 
=== Force-pushing policy ===
  
A '''forced push''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].
+
A '''<dfn>forced push</dfn>''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].
  
  git push --force fork <var><branch name></var>
+
  '''>''' git push --force fork <var><branch name></var>
  
 
However, for a public repository depended upon by more than a handful people like any of the <cite>Wesnoth</cite> repositories at [https://github.com/wesnoth <https://github.com/wesnoth>], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, <strong>force-pushing to the upstream <cite>Wesnoth</cite> repositories is <em>NOT allowed</em> unless specifically authorized by the repository administrators in order to resolve an urgent issue</strong>.
 
However, for a public repository depended upon by more than a handful people like any of the <cite>Wesnoth</cite> repositories at [https://github.com/wesnoth <https://github.com/wesnoth>], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, <strong>force-pushing to the upstream <cite>Wesnoth</cite> repositories is <em>NOT allowed</em> unless specifically authorized by the repository administrators in order to resolve an urgent issue</strong>.
Line 110: Line 144:
 
Do this from inside the ''wesnoth'' directory:
 
Do this from inside the ''wesnoth'' directory:
  
  git pull
+
  '''>''' git pull
  
 
== Reviewing your changes ==
 
== Reviewing your changes ==
Line 116: Line 150:
 
Before committing, it's always wise to run:
 
Before committing, it's always wise to run:
  
  git diff
+
  '''>''' git diff
  
 
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.
 
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.
Line 124: Line 158:
 
Under Git on a Unix-like operating system, you'll typically do
 
Under Git on a Unix-like operating system, you'll typically do
  
  git format-patch HEAD~1..HEAD
+
  '''>''' git format-patch HEAD~1..HEAD
  
 
or something similar; "HEAD~1" may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension ".patch".  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.
 
or something similar; "HEAD~1" may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension ".patch".  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.
Line 132: Line 166:
 
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.
 
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.
  
  git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git
+
  '''>''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git
  
 
You can then push your branches to your fork:
 
You can then push your branches to your fork:
  
  git push fork branch_name
+
  '''>''' git push fork branch_name
  
 
Or, if you want to push one branch in your local repository to another in the remote repository:
 
Or, if you want to push one branch in your local repository to another in the remote repository:
  
  git push fork local_branch_name:remote_branch_name
+
  '''>''' git push fork local_branch_name:remote_branch_name
  
 
You can then create pull requests from your branches in GitHub’s Web interface.
 
You can then create pull requests from your branches in GitHub’s Web interface.
Line 146: Line 180:
 
== See Also ==
 
== See Also ==
  
* [[CompilingWesnoth]]
+
* [[Git for Wesnoth Crash Course]]
* [[Git_for_Wesnoth_Crash_Course]]
+
 
 
[[Category:Development]]
 
[[Category:Development]]

Latest revision as of 08:52, 19 July 2024

[edit]Compiling Wesnoth

Platforms

The Battle for Wesnoth code-base is stored in a version control repository. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.

When a release is planned, the current set of the files in the repository is "frozen", given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or "repo") version is by definition the most up-to-date version of the code.

The Wesnoth repository is a Git repository and is hosted on GitHub:

What is Git?

Are you a newcomer to Git or GitHub who would like to work on Wesnoth?
If so, you may find iceiceice's Git for Wesnoth Crash Course to be a useful read -- while WesnothRepository is also beginner-focused, it's not as extensive as iceiceice's Crash Course).

Git is the most widely used open-source version-control system. You can learn more about it at its website:

Git replaced Subversion (SVN) as Wesnoth's version-control system in March 2013. Subversion had, itself, previously replaced an older program, Concurrent Versioning System (CVS), in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.

Browse the code

Want a GUI for Git?
SmartGit is cross-platform and supposedly powerful, and the IDEs Qt Creator and Microsoft Visual Studio provide Git GUIs. However, the official Git command-line program is by far the easiest Git program to get help with -- you may well have trouble finding people who can help you with a Git GUI.

You can use a Web browser to view the source code at the following Web address:

There are currently two main streams of development ("branches"): the master branch (1.19.x), and the stable branch (1.18.x). (1.16.x is now oldstable.) Most other branches are only used for a short time to do some testing without disturbing the main development.

Download

To clone a copy of the repository into a directory named "wesnoth", run this command:

> git clone "https://github.com/wesnoth/wesnoth.git" wesnoth
Technical aside: Git transport protocols
There are other transport protocols, in addition to Hypertext Transfer Protocol Secure (HTTPS), over which one can clone a Git repository from GitHub, including:
  • Secure Shell (SSH) ("ssh://git@github.com/wesnoth/wesnoth.git", or "git@github.com:wesnoth/wesnoth.git"), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the "Push access" section, below).
  • Git's native transport protocol ("git://github.com/wesnoth/wesnoth.git"), which may be somewhat faster than HTTPS (though GitHub uses a faster "smart" HTTPS transport), but is insecure and should be used (if one must use it) with caution (check the commit hashes!).

A more detailed explanation is available here.

(Note: the ">" sigil represents a command prompt; don't type it in.)

FAQ

Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?

A: https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection

  1. Use a download manager to download the directory "https://github.com/wesnoth/wesnoth.git", in one or more sessions.
  2. Put this "wesnoth.git" directory, which is the internals of the Wesnoth repository, in a new, empty directory.
  3. Rename the "wesnoth.git" directory to ".git".
  4. Finally, run these commands in the directory that contains the ".git" directory:
> git remote add remote "https://github.com/wesnoth/wesnoth.git"
> git reset --hard HEAD

The first command links your local repository to the upstream repository; the second checks out a working tree (i.e., copies the files out of the ".git" directory into a form that you can use).

Alternative: This will make a shallow clone and allow you to fetch additional history as desired.

  1. Start by using a clone command
  2. Run a git fetch command with an increased depth, such as "git fetch --depth=2000"
  3. Continue to run additional fetch commands, each time increasing the depth, based on what your connection can handle. As of this writing, the max depth is around 60-70K.
  4. When an increase in depth no longer brings additional data, verify you have a complete repository by using "git fetch --unshallow"
  5. To fix the single branch checkout aspect, use git config and fetch commands.

A sample sequence is shown below. You may want to use smaller depth increases (i.e.,2-5K) based on your connection speed and reliability.

> git clone --depth 1 "https://github.com/wesnoth/wesnoth.git" wesnoth
> git fetch --depth=10000
> git fetch --depth=20000
> git fetch --depth=30000
> git fetch --depth=40000
> git fetch --depth=50000
> git fetch --depth=60000
> git fetch --depth=70000
> git fetch --unshallow
> git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
> git fetch origin

Q: I don't want any alternate branches or repository history. How could I avoid downloading that?

A: This simply requires a more elaborate command. For example, to only download the last revision of the 1.18 branch, and store it in a directory named "wesnoth-1.18-single-branch-test":

> git clone --branch 1.18 --single-branch --depth 1 "https://github.com/wesnoth/wesnoth.git" wesnoth-1.18-single-branch-test

Example results:

> git clone --branch 1.18 --single-branch --depth 1 "https://github.com/wesnoth/wesnoth.git" wesnoth-1.18-single-branch-test
Cloning into 'wesnoth-1.18-single-branch-test'...
remote: Counting objects: 20751, done.
remote: Compressing objects: 100% (20087/20087), done.
remote: Total 20751 (delta 968), reused 11881 (delta 416), pack-reused 0
Receiving objects: 100% (20751/20751), 444.98 MiB | 636.00 KiB/s, done.
Resolving deltas: 100% (968/968), done.
Checking out files: 100% (20369/20369), done.
> du -sh wesnoth-1.18-single-branch-test # "du" means "disk usage".
1.3G	wesnoth-1.18-single-branch-test

However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.

Push access

For push access (the capability to push changes from your local repository) to our upstream repository on GitHub, you must have an account on GitHub, which must be registered as part of the Battle for Wesnoth organization.

It may be convenient to use Git's Secure Shell (SSH) transport protocol, so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH key pair with a command like (on Unix descendent operating systems, including Linux distributions and Apple macOS, at least) this:

> ssh-keygen -t ed25519 -f "<file>" -C "<your name>'s SSH key for GitHub"

On a typical Linux distribution or on Apple macOS, <file> would be, e.g., "~/.ssh/id-key-for-github".

Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally "~/.ssh/config"):

Host github.com
	IdentityFile <file>

Then register the key with GitHub, by going to <https://github.com/settings/ssh>, selecting "Add SSH key", and pasting the contents of the public key file (<file>, but with a ".pub" extension) into the "Key" field.

Then, if you have not yet cloned the repository, clone it via SSH:

> git clone "ssh://git@github.com/wesnoth/wesnoth.git" wesnoth

If you have already cloned the repository, you can set it to use SSH transfer:

> git remote set-url origin "ssh://git@github.com/wesnoth/wesnoth.git"

You can also leave your local repo using the read-only URL, and add a pushurl. Manually editing the .git/config also allows it to be commented-out to avoid accidentally pushing to it instead of a fork:

 [remote "origin"]
 	url = https://github.com/wesnoth/wesnoth
 	# pushurl = git@github.com:wesnoth/wesnoth.git
 	fetch = +refs/heads/*:refs/remotes/origin/*

Force-pushing policy

A forced push rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own personal fork.

> git push --force fork <branch name>

However, for a public repository depended upon by more than a handful people like any of the Wesnoth repositories at <https://github.com/wesnoth>, force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, force-pushing to the upstream Wesnoth repositories is NOT allowed unless specifically authorized by the repository administrators in order to resolve an urgent issue.

Update

Do this from inside the wesnoth directory:

> git pull

Reviewing your changes

Before committing, it's always wise to run:

> git diff

and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.

Generating patches

Under Git on a Unix-like operating system, you'll typically do

> git format-patch HEAD~1..HEAD

or something similar; "HEAD~1" may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension ".patch". See PatchSubmissionGuidelines for more on how to get these merged into the public repository.

Push to your own fork

If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.

> git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git

You can then push your branches to your fork:

> git push fork branch_name

Or, if you want to push one branch in your local repository to another in the remote repository:

> git push fork local_branch_name:remote_branch_name

You can then create pull requests from your branches in GitHub’s Web interface.

See Also

This page was last edited on 19 July 2024, at 08:52.