Editing Mercurial

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 2: Line 2:


Everybody is free to '''run, copy, distribute, study, change and improve'''<ref>https://www.gnu.org/philosophy/free-sw.en.html</ref> Octave's source code, given in the main repository at https://www.octave.org/hg/octave.  Use Mercurial to get the latest version of Octave <pre>hg clone https://www.octave.org/hg/octave</pre>
Everybody is free to '''run, copy, distribute, study, change and improve'''<ref>https://www.gnu.org/philosophy/free-sw.en.html</ref> Octave's source code, given in the main repository at https://www.octave.org/hg/octave.  Use Mercurial to get the latest version of Octave <pre>hg clone https://www.octave.org/hg/octave</pre>
== Workflow reference ==
This section gives several frequently used Mercurial commands and sequences.
* Initial clone: <pre>hg clone https://hg.savannah.gnu.org/hgweb/octave/</pre>
You can then bootstrap, configure and make, make check, maybe make install.
* To update on a regular basis, you can do <pre>hg pull -u</pre> or <pre>hg pull && hg up</pre>
* To make a ''local clone'', you can clone from your main Octave repository on your computer to another directory like this: <pre>hg clone octave myfeature</pre> which will clone the Octave directory into a new directory called "myfeature". You'll need to cd to the correct directory first. Then you can cd into the new directory and run bootstrap, configure, make. To prevent a fresh download of gnulib, you can specify the path to the first Octave directory's gnulib if you want.
It is best practice to make a new clone directory for each feature or bugfix you work on, which makes recovery from mistakes much easier.
* To work on the stable branch instead of the default branch, make a local clone called "stable", then cd to it and <pre>hg update stable</pre>
* To circulate work-in-progress bugfixes: first cd to the relevant local clone, then edit the relevant files, verify that it builds, then <pre>hg diff &gt;/tmp/my.wip.patch</pre> and then upload that file to the bug tracker discussion. You can also copy-paste it into a bug discussion using ''verbatim'' tags if the patch is small enough. Accept feedback from the bug discussion and iterate your patch.
* When you're ready to commit your fix, first pull and update your main Octave directory from Savannah, then pull and update your local clones. Then build again to make sure things haven't broken. Then <pre>hg commit</pre> and type a summary and context for your change. Exit the editor, saving when it prompts. Build again so your build gets the latest hg id. Type <pre>hg export &gt;/tmp/my.patch</pre> and upload that file into the bug discussion. Wait for a maintainer to apply it with your name, then if you do <pre>hg in</pre> in your main Octave directory it'll show up as an incoming change. Do a pull and up to get that, then do a pull and up in your individual clone directories to get it there.
* To merge changes from stable to default <pre>hg merge stable</pre>. It's best to run this only in local clones that are already on the default branch. That way, local clones on stable don't have to switch branches before merging.
* To push to a repository, if you have push rights to that repository, you can see what's going out with <pre>hg out</pre> and then if you're happy with it you can<pre>hg push</pre>.
==Tutorials==
Joel Spolsky's Mercurial tutorial: [https://hginit.github.io/01.html https://hginit.github.io/01.html]


{{Note|[https://tortoisehg.bitbucket.io/ TortoiseHg] is a GUI for Mercurial and it is especially recommended for users doing their first steps with source code management systems.  Linux, macOS, and MS Windows are supported.}}
{{Note|[https://tortoisehg.bitbucket.io/ TortoiseHg] is a GUI for Mercurial and it is especially recommended for users doing their first steps with source code management systems.  Linux, macOS, and MS Windows are supported.}}
Line 185: Line 159:
=== Activate the "mq" extension ===
=== Activate the "mq" extension ===


The "mq" extension allows to modify (local) changesets after they have been committed. It also allows to rebase changes to a new parent or to strip changes completely.
The "mq" extensions allow to modify (local) changeset after they have been committed. They also allow to rebase changes to a new parent or to strip changes completely.
The "mq" extension does *not* allow to modify pushed changes.
The "mq" extensions do *not* allow to modify pushed changes.
 
To activate the "mq" extension in TortoiseSVN, open the settings, select "Extensions" on the global settings tab and activate the checkbox next to "mq".


The most useful feature of that extension is probably to update an existing changeset. For this, select "Modify History" -> "Import to MQ" in the right click menu of the respective changeset. After updating some local files or changing the commit message, hit the "QRefresh" button. Finish the patch by selecting "Modify History" -> "Finish Patch" from the right click menu of the respective changeset.
To activate the "mq" extensions in TortoiseSVN, open the settings, select "Extensions" on the global settings tab and activate the checkbox next to "mq".


=== Rebase a change to a current tip ===
=== Rebase a change to a current tip ===


Sometimes a change in the upstream repository might make it necessary to rebase a changeset to a new parent. There are several ways to achieve this. The ways described here might not be the most elegant ones. Any editor is welcome to add onto this.
Sometime a change of the upstream repository might make it necessary to rebase a changeset to a new parent. There are several ways to achieve this. The ways described here might not be the most elegant ones. Any editor is welcome to add onto this.


Strip and commit:
Strip and commit:
# Pull changes from the upstream repository.
# Pull changes from the upstream repository.
# Before updating to the new tip, strip the local changes by selecting "Modify History" -> "Strip..." from the right click menu. In the dialog, select "Do not modify working copy during strip (-k/--keep)".
# Before updating to the new tip, strip the local changes by selecting "Modify History" -> "Strip..." from the right click menu. In the dialog select, "Do not modify working copy during strip (-k/--keep)".
# Update to the new tip (maybe in incremental steps).
# Update to the new tip (maybe in incremental steps).
# Commit the local changes in a "fresh" changeset. This has the drawback that any commit message might be lost. But it often works even if other approaches fail.
# Commit the local changes in a "fresh" changeset. This has the drawback that any commit message might be lost. But it often works even if other approaches fail.
Please note that all contributions to Octave may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Octave:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)