Mercurial: Difference between revisions

Jump to navigation Jump to search

Mercurial (edit)

Revision as of 21:51, 14 June 2022

2,854 bytes added ,  14 June 2022
→‎Creating and submitting patches (changesets): more of the same
(23 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[https://www.mercurial-scm.org Mercurial] (sometimes referred to as {{codeline|hg}}) is the source code management system used for Octave development.
[https://www.mercurial-scm.org Mercurial] (sometimes referred to as {{codeline|hg}}) is the source code management system used for Octave development.
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://hg.octave.org/octave</pre>


{{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 5: Line 7:
== Creating and submitting patches (changesets) ==
== Creating and submitting patches (changesets) ==


Everybody is free to run, copy, distribute, study, change and improve Octave's source code, given in the main repository at https://www.octave.org/hg/octave.  If you want to share your modifications, for example to fix a nasty '''bug #42424''', you cannot just submit your changes to Octave's main repository.  You have to generate a '''patch (or changeset)''' so other Octave developers can include them into Octave's source code.
If you want to share your modifications, for example to fix a nasty '''bug #42424''', you cannot just submit your changes to Octave's main repository.  You have to generate a '''patch (or changeset)''' so other Octave developers can include them into Octave's source code.


# Get the latest revision of Octave (or some Octave package) <pre>hg clone https://www.octave.org/hg/octave</pre> or when already cloned <pre>hg pull && hg update</pre>
# Get the latest version of Octave (or some Octave package) <pre>hg clone https://hg.octave.org/octave</pre> or when already cloned <pre>hg pull && hg update</pre>
# Make your changes (fix bug #42424) and save them.  '''Make sure that your changes don't introduce new bugs!'''  Thus it is recommended to [[Building | build Octave]] and to [[Tests | run Octave's test suite]] before proceeding.<br>{{Warning|Please follow the [[Contribution guidelines]] for C/C++ or Octave code files!}}
# Make your changes (fix bug #42424) and save them.  '''Make sure that your changes don't introduce new bugs!'''  Thus it is recommended to [[Building | build Octave]] and to [[Tests | run Octave's test suite]] before proceeding.<br>{{Warning|Please follow the [[Contribution guidelines]] for C/C++ or Octave code files!}}
# Commit your changes <pre>hg commit</pre> Mercurial will open your default editor<ref>To set your default Mercurial editor, read https://www.mercurial-scm.org/wiki/editor .</ref> and ask you for a commit message.  Please follow the [[commit message guidelines]], e.g. <syntaxhighlight lang="text">help.m: Display relevant topics first (bug #42424)
# Commit your changes <pre>hg commit</pre> Mercurial will open your default editor<ref>To set your default Mercurial editor, read https://www.mercurial-scm.org/wiki/editor .</ref> and ask you for a commit message.  Please follow the [[commit message guidelines]], e.g. <syntaxhighlight lang="text">help.m: Display relevant topics first (bug #42424)
Line 19: Line 21:
# Node ID 68c698c4f2fd98bf2d48234bd1da99e91763114f
# Node ID 68c698c4f2fd98bf2d48234bd1da99e91763114f
# Parent  f5c9bb5955e7c9fddef5c3c3f115201e11b43b79
# Parent  f5c9bb5955e7c9fddef5c3c3f115201e11b43b79
help.m: Display relevant topics first (bug #42424)
help.m: Display relevant topics first (bug #42424)


Line 66: Line 69:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
hg pull https://www.octave.org/hg/octave       # Get latest changes from main repo, bookmark "@"
hg pull https://www.octave.org/hg/octave   # Get latest remote "tip"
hg update -r my-gsoc                           # Select my bookmark
hg update -r my-gsoc                       # Activate bookmark "my-gsoc"
hg merge @                                    # Merge changes of bookmark "@" to bookmark "my-gsoc"
hg merge tip                              # Merge "tip" into "my-gsoc"
hg commit -m "maint: merge default to my-gsoc"
hg commit -m "maint: merge default to my-gsoc"
hg push ssh://student@public.server.org/octave
hg push ssh://student@public.server.org/octave
Line 75: Line 78:
=== Preparing for code reviews ===
=== Preparing for code reviews ===


At the time of the mid-term or final review (or whenever the mentor requires it) students should prepare their code  
At the time of the mid-term or final review (or whenever the mentor requires it) students should prepare their code for review and possibly inclusion into the main repository.
for review and possibly inclusion into the main development branch. To this end students should:
 
<ol>
# Create a full log of changes <pre>hg log --template=changelog --no-merges --user student-name</pre> If students have been following the [[Commit message guidelines]] the output is a good starting point for the commit message in the next step. Some manual post-processing might be necessary:
<li> prepare a full log of their changes, listing files that have been touched
#* Each touched file should appear only once.
and including a summary of the purpose of those changes. If students have been following
#* Do not mention backed-out commits.
the [[Commit message guidelines]] the following command will give a good starting point<br>
# Prepare a singe patch (changeset) including all code that should be submitted for review <syntaxhighlight lang="bash">
<code> hg log --style=changelog --no-merges --user student-name </code><br>
hg pull https://www.octave.org/hg/octave  # Get remote "tip" and "@"
this message should be edited so that
hg update -r @                             # Activate    bookmark "@"
  <ol  style="list-style-type: lower-roman;">
hg merge my-gsoc                          # Merge "my-gsoc" into "@"
<li> each touched file appears only once </li>
hg commit
<li> changes that were backed out should not be mentioned <!--(like changeset "H" in the above example)--> </li>
hg export -r tip -o mid-term-review.patch
</ol>
</syntaxhighlight> The file {{Path|mid-term-review.patch}} can uploaded to the [https://savannah.gnu.org/patch/?group=octave patch tracker]. <br/> Finally, there is a subtle difference between <code>"tip"</code>, which is a reference to the (local or remote) changeset added to the repository most recently and the bookmark <code>"@"</code> used by the Octave developers to point to the latest remote changeset.  Often both refer to the very same changeset and they can used interchangeably.
The main  purpose of this log is to make it easy, not only for the main mentor, but also for other developers who
have not been closely following the progress of the project to quickly understand where to look at in the code to evaluate it, but it will also be used as the commit message for the merge changeset, so it should itself comply with the [[Commit message guidelines]].
<li> prepare a merge changeset including all the code that should be submitted for review
  <ol style="list-style-type: lower-roman;">
  <li> pull from the main repository<br/>
  <code>hg pull https://www.octave.org/hg/octave</code></li>
   <li> move to the top of the main line of development and merge in the feature branch<br/>
  <code>hg up -r @</code><br/>
  <code>hg merge student-bookmark-name </code><br/></li>
  <li> create a changeset, export it and send to the mentor for review, remember to use the log created above as a commit message<br/>
  <code>hg commit </code><br/>
  <code>hg export @ > mid-term-review.changeset </code><br/>
  the file mid-term-review.changeset can then be sent to the [mailto:octave-maintainers@octave.org mailing list] or posted
  to the [https://savannah.gnu.org/patch/?group=octave patch tracker]</li>
  </ol> </li>
</ol>


== Example Mercurial configuration ==
== Example Mercurial configuration ==
Line 163: Line 150:
[alias]
[alias]
glog = log --graph
glog = log --graph
top = log --graph -l
top = log --graph -l
</syntaxhighlight>}}
</syntaxhighlight>}}
== Tips for working with TortoiseHg ==
TortoiseHg is a multi-platform graphical user interface for Mercurial repositories. It allows to perform many hg operations using the context menu and toolbar buttons. That might make it easier to get used to working with Mercurial.
=== 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" extension does *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.
=== 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.
Strip and commit:
# 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)".
# 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.
Un-apply and re-apply:
# Pull changes from the upstream repository.
# Before updating to the new tip, import the local changeset to mq by selecting "Modify History" -> "Import to MQ" in the right click menu.
# You might want to refresh the changeset with local changes.
# Un-apply the patch by selecting "Modify History" -> "Unapply Patch" from the right click menu. If there are other, un-committed changes in the local repository, you might want to select "Tolerate non-conflicting local changes (--keep-changes)" in the "Modify History" -> "MQ Options" dialog from the right click menu beforehand.
# Update to the new tip.
# Select the previously unapplied patch on top of the revision graph and re-apply it by using the "Reapply Patch" option in the right click menu. This has the advantage that a commit message will be retained. But re-applying the patch might fail if there were changes in the upstream repository that made the patch incompatible.
Rebase:
# Pull changes from the upstream repository.
# Select the local changeset that you'd like to rebase.
# Hold down the Ctrl key and select the changeset that should be the new parent of the local changeset (probably the new tip).
# Right-click the changeset of the new parent and select "Rebase...".
# The default settings are often times fine. This process has the advantage that a commit message will be retained and it often times resolves conflicts automatically. But it doesn't work if there are any un-committed local changes.


== Footnotes ==
== Footnotes ==
ArunGiridhar
171

edits

Retrieved from "https://wiki.octave.org/Special:MobileDiff/13163...14384"

Navigation menu