Git for Wesnoth Crash Course - Revision history

Egallager: link cleanup

2023-04-18T06:25:13Z

link cleanup

Doofus-01: gitref.org link does not currently lead to a useful web-page, I have tried to provide an alternative resource.

2017-07-03T03:06:21Z

gitref.org link does not currently lead to a useful web-page, I have tried to provide an alternative resource.

DeFender1031: /* Setting up our workflow for Wesnoth in Git */ just asked. Apparently aliases are good too as long as they remain consistent.

2016-10-27T19:37:42Z

‎Setting up our workflow for Wesnoth in Git: just asked. Apparently aliases are good too as long as they remain consistent.

Aquileia: Delete two entries of the addendum

2015-07-27T17:15:33Z

Delete two entries of the addendum

8680: /* Filing a pull request */ Actually fix link

2015-07-27T17:08:30Z

‎Filing a pull request: Actually fix link

8680: /* Filing a pull request */ Fix link

2015-07-27T17:08:06Z

‎Filing a pull request: Fix link

8680: /* Filing a pull request */ Fix invalid HTML

2015-07-25T05:57:20Z

‎Filing a pull request: Fix invalid HTML

8680 at 04:19, 25 July 2015

2015-07-25T04:19:42Z

8680: Extensive edit, but not making high-level semantic changes

2015-07-25T04:16:29Z

Extensive edit, but not making high-level semantic changes

Show changes

Iceiceice: fixup clean slate

2014-06-12T14:59:12Z

fixup clean slate

@@ Line 3: / Line 3: @@
 '''''(An essay by, mainly, iceiceice.)'''''
-This page is intended for new <cite>Battle for Wesnoth</cite> developers and contributors who have never used '''[//wiki.wesnoth.org/WesnothRepository <cite>Git</cite>]''' before. I'm hoping that it will be written <em>mainly</em> by newbies like myself who have just figured out enough about <cite>Git</cite> to use it successfully, and therefore not include a bunch of information superfluous for that purpose. At the time that I am writing this, I have managed to write about eight GitHub pull requests and get them merged into <cite>Wesnoth</cite>, and I hope you will be able to do the same after reading this.
+This page is intended for new <cite>Battle for Wesnoth</cite> developers and contributors who have never used '''[[WesnothRepository|<cite>Git</cite>]]''' before. I'm hoping that it will be written <em>mainly</em> by newbies like myself who have just figured out enough about <cite>Git</cite> to use it successfully, and therefore not include a bunch of information superfluous for that purpose. At the time that I am writing this, I have managed to write about eight GitHub pull requests and get them merged into <cite>Wesnoth</cite>, and I hope you will be able to do the same after reading this.
 == What is <cite>Git</cite>? ==
@@ Line 131: / Line 131: @@
 <p><strong>A commit message should fully explain what changes were made in the commit, and <em>why</em> those changes were made</strong>. A good commit message is structured like an email message.</p>
-<p>The first line, which <strong>summarizes</strong> the commit, has special importance -- to quote the <cite>[[DeveloperGuide]]</cite> page, <q cite="http://wiki.wesnoth.org/DeveloperGuide#Commit_messages">This is the first (and often the only) line someone using browsing tools will see</q>. It should ideally be at most 80 characters (TODO: inconsistent with current policy), and is like the subject line of an email message. Commit message summary lines should be written in the imperative present tense, e.g., "Add field to <var>some_class</var>, with accessor methods", "Fix <var>other_class</var>'s constructor", "Delete unnecessary #include", etc.</p>
+<p>The first line, which <strong>summarizes</strong> the commit, has special importance -- to quote the <cite>[[DeveloperGuide]]</cite> page, <q cite="[[DeveloperGuide#Commit_messages]]">This is the first (and often the only) line someone using browsing tools will see</q>. It should ideally be at most 80 characters (TODO: inconsistent with current policy), and is like the subject line of an email message. Commit message summary lines should be written in the imperative present tense, e.g., "Add field to <var>some_class</var>, with accessor methods", "Fix <var>other_class</var>'s constructor", "Delete unnecessary #include", etc.</p>
 <p>After the summary line, there must be a blank line, after which comes the '''commit message body''', which is analogous to the body of an email message.</p>
@@ Line 137: / Line 137: @@
 <p>'''Optimally''', a commit's message would be so clearly and comprehensively explanatory that it would answer any questions that anyone might have about the commit, now, the next day, or years into the future -- which is especially important because the author of the commit likely won't always be around to answer those questions.</p>
-<p>See also [//wiki.wesnoth.org/DeveloperGuide#Commit_messages the <cite>DeveloperGuide</cite> page's "Commit messages" section] and [https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines the official Git book's "Commit Guidelines" section].</p>
+<p>See also [[DeveloperGuide#Commit_messages|the <cite>DeveloperGuide</cite> page's "Commit messages" section]] and [https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines the official Git book's "Commit Guidelines" section].</p>
 </li>
 <li>
@@ Line 150: / Line 150: @@
 <p><strong>It is better to commit more often than less often</strong>, because, before you submit your changes to upstream, you will have the opportunity to edit your commit history, and <strong>it is much easier to ''squash'' commits together than to split up an overly-large commit</strong>.</p>
-<p>See also [//wiki.wesnoth.org/DeveloperGuide#Commits the <cite>DeveloperGuide</cite> page's "Commits" section].</p>
+<p>See also [[DeveloperGuide#Commits|the <cite>DeveloperGuide</cite> page's "Commits" section]].</p>
 </li>
 <li>
@@ Line 163: / Line 163: @@
 <p>If this is your first commit, the development team will ask you to add an appropriate note about yourself in the '''credits document''', '''<code>data/about.cfg</code>'''.</p>
-<p>See also [//wiki.wesnoth.org/DeveloperGuide#Changelogs_and_release_notes the <cite>DeveloperGuide</cite> page's "Changelogs and release notes" section].</p>
+<p>See also [[DeveloperGuide#Changelogs_and_release_notes|the <cite>DeveloperGuide</cite> page's "Changelogs and release notes" section]].</p>
 </li>
 </ol>
@@ Line 248: / Line 248: @@
 At the time of writing this, we also have configured [https://travis-ci.org Travis CI], a [https://en.wikipedia.org/wiki/Continuous_integration continuous integration] system, to automatically try to compile <cite>Wesnoth</cite> with your changes, to make sure that it still works before your pull request is granted. However, it is not mandatory for the Travis build to complete successfully for the pull request to be granted. Additionally, you may still make changes to your pull request by pushing more changes to your topic branch in your fork, after which Travis <em>should</em> try to compile the updated topic branch. You can even still force push to erase the content of the topic branch (on which the pull request is based) and replace it with new content -- however, you shouldn't file a pull request for a topic branch until you are ready for it to be merged.
-Now, wait for a member of the development team to review your pull request. You can often find someone on the development [//wiki.wesnoth.org/Support#IRC IRC] channel, <code>#wesnoth-dev</code>. Additionally, developers may comment directly on your pull request with questions, so you should check it periodically.
+Now, wait for a member of the development team to review your pull request. You can often find someone on the development [[Support#IRC|IRC]] channel, <code>#wesnoth-dev</code>. Additionally, developers may comment directly on your pull request with questions, so you should check it periodically.
 === Cleaning up at the end ===

@@ Line 7: / Line 7: @@
 == What is <cite>Git</cite>? ==
-The most effective '''"absolute beginner" introduction to <cite>Git</cite>''' that I found when I started is here: '''[http://gitref.org <cite>gitref.org</cite>]'''.
+The most effective '''"absolute beginner" introduction to <cite>Git</cite>''' that I found when I started is here: '''[http://gitref.org <cite>gitref.org</cite>]'''. - ''(Note: this gitref.org link seems to have died.  Another resource, that is only slightly less introductory-level, is '''[https://git-scm.com/book/en/v2 <cite>Pro-Git Book</cite>]'''.  Don't worry about reading the whole thing though.)''
 I suggest that you <strong>read this through</strong>, beginning to end, navigating through the pages by using the red arrows at the bottom of each page. You can skip the part about ''"stashing"'', but you should carefully read and understand the parts about:

@@ Line 38: / Line 38: @@
 </ol>
-Additionally, we ask that you configure <cite>Git</cite> to use your full real name, per the instructions in [https://help.github.com/articles/setting-your-username-in-git/ GitHub's "<cite>Setting your username in Git</cite>" help article], so that we can associate a concrete person with every commit merged into <cite>Wesnoth</cite>. Your GitHub profile should also display your real name.
+Additionally, we ask that you configure <cite>Git</cite> to use your full real name or a consistent alias, per the instructions in [https://help.github.com/articles/setting-your-username-in-git/ GitHub's "<cite>Setting your username in Git</cite>" help article], so that we can associate a concrete person with every commit merged into <cite>Wesnoth</cite>. Your GitHub profile should also display the same name.
 == The basic workflow ==

@@ Line 383: / Line 383: @@
-control with which repo you interact
+If a command goes awry, you can go to "git reflog", find the point just before you typed it, and reset --hard to that commit, and it should be like the bad thing never happened
 revert every file in the repo to look like it did at the HEAD commit (last successful sync)
@@ Line 423: / Line 417: @@
 * don't forget the changelog (and, for visible changes, the players_changelog)
-* try to keep the summary at 50 characters or less, maximum 72<br>commit meter in units of 10 chars:
+* try to keep the summary at 50 characters or less, maximum 72
 == See Also ==

@@ Line 248: / Line 248: @@
 At the time of writing this, we also have configured [https://travis-ci.org Travis CI], a [https://en.wikipedia.org/wiki/Continuous_integration continuous integration] system, to automatically try to compile <cite>Wesnoth</cite> with your changes, to make sure that it still works before your pull request is granted. However, it is not mandatory for the Travis build to complete successfully for the pull request to be granted. Additionally, you may still make changes to your pull request by pushing more changes to your topic branch in your fork, after which Travis <em>should</em> try to compile the updated topic branch. You can even still force push to erase the content of the topic branch (on which the pull request is based) and replace it with new content -- however, you shouldn't file a pull request for a topic branch until you are ready for it to be merged.
-Now, wait for a member of the development team to review your pull request. You can often find someone on the development [/Support#IRC IRC] channel, <code>#wesnoth-dev</code>. Additionally, developers may comment directly on your pull request with questions, so you should check it periodically.
+Now, wait for a member of the development team to review your pull request. You can often find someone on the development [//wiki.wesnoth.org/Support#IRC IRC] channel, <code>#wesnoth-dev</code>. Additionally, developers may comment directly on your pull request with questions, so you should check it periodically.
 === Cleaning up at the end ===

@@ Line 224: / Line 224: @@
 === Filing a pull request ===
-When you finish working on your feature or bug fix, select your topic branch on your fork (with the "Branch" menu), and click the green button to file a pull request. By default, the target of the pull request -- the repository and branch into which it is requesting that your changes be pulled -- will be "<samp>wesnoth:master</samp>", the <code>master</code> branch of the main <cite>Wesnoth<cite> repository.
+When you finish working on your feature or bug fix, select your topic branch on your fork (with the "Branch" menu), and click the green button to file a pull request. By default, the target of the pull request -- the repository and branch into which it is requesting that your changes be pulled -- will be "<samp>wesnoth:master</samp>", the <code>master</code> branch of the main <cite>Wesnoth</cite> repository.
 The message that you enter for the pull request should become the commit message of the merge operation performed in the upstream repository if the pull request is granted. (Note: if you are granting someone's PR through the GitHub Web interface, please ensure that this happens.)

← Older revision		Revision as of 04:19, 25 July 2015
Line 1:		Line 1:
		+	== Foreword ==
		+
	'''''(An essay by, mainly, iceiceice.)'''''		'''''(An essay by, mainly, iceiceice.)'''''
−
−	~~== Foreword ==~~

	This page is intended for new <cite>Battle for Wesnoth</cite> developers and contributors who have never used '''[//wiki.wesnoth.org/WesnothRepository <cite>Git</cite>]''' before. I'm hoping that it will be written <em>mainly</em> by newbies like myself who have just figured out enough about <cite>Git</cite> to use it successfully, and therefore not include a bunch of information superfluous for that purpose. At the time that I am writing this, I have managed to write about eight GitHub pull requests and get them merged into <cite>Wesnoth</cite>, and I hope you will be able to do the same after reading this.		This page is intended for new <cite>Battle for Wesnoth</cite> developers and contributors who have never used '''[//wiki.wesnoth.org/WesnothRepository <cite>Git</cite>]''' before. I'm hoping that it will be written <em>mainly</em> by newbies like myself who have just figured out enough about <cite>Git</cite> to use it successfully, and therefore not include a bunch of information superfluous for that purpose. At the time that I am writing this, I have managed to write about eight GitHub pull requests and get them merged into <cite>Wesnoth</cite>, and I hope you will be able to do the same after reading this.

@@ Line 338: / Line 338: @@
 get a clean slate by syncing with upstream
          git fetch upstream
          git checkout -B master upstream/master