We are currently indexing your data, so search results may be incomplete until we finish.
|
|
Commit
======
.. module:: commit.dialog
:synopsis: Dialog used to perform commit
.. warning::
The win32text extension can cause trouble with hunk selection. This
has been resolved in Mercurial 1.3 and TortoiseHg 0.8, but requires
proper configuration. See
`issue #82 <http://bitbucket.org/tortoisehg/stable/issue/82/>`_.
The commit tool is an important part of TortoiseHg. It is, in fact, the
only component that defaults to the top level shell context menu. This
is mainly because it is the most heavily used tool. Not only can you
commit your changes, but you can examine the state of your working
directory and perform most routine maintenance tasks (add new files,
record renames, manage the repository ignore filter, etc).
.. figure:: figures/commit.png
:alt: Commit dialog
Commit dialog
Features
--------
Walking across the toolbar buttons:
:guilabel:`Refresh`
Reload the state of the working directory. It tries to retain
check and selection state across refresh.
:guilabel:`Commit`
Commit selected diffs in checked files.
:guilabel:`Undo`
Undo (rollback) last immediate commit. Your commit message will be
available in the message history, so you can re-do the commit after
fixing whatever problem you noticed.
:guilabel:`Revert`
Revert checked files to last revisioned state. If merging, it
allows you to select the revert parent.
:guilabel:`Add`
Add checked files that were in unknown '?' or ignored 'I' state.
:guilabel:`Move`
Move checked files to specified target directory in versioned
manner.
:guilabel:`Remove`
Delete checked unversioned files and/or remove (mark as deleted) any
versioned files.
Below the toolbar are useful widgets:
:guilabel:`Branch dialog`
Shows the current branch name of the working directory. Normally
this is informational only, but pressing this button opens up a
branch maintenance dialog. Do not use this feature unless you
understand Mercurial's
`named branches <http://mercurial.selenic.com/wiki/NamedBranches>`_.
:guilabel:`Recent Commit Messages`
A drop-down list of the 10 most recent commit messages. The
the drop-down list is filled the first time it is opened.
:guilabel:`QNew`
If you have enabled the MQ extension, there will also be a text
entry for a new patch name. Entering a patch name switches the
commit tool into 'QNew' mode.
The file list has four columns:
1) A checkbox that indicates whether the file is selected for an
operation. The toolbar buttons only operate on checked files.
"Partially" selected files have a special check state. This
column header is checkable, it will toggle the file selection
states.
2) The :guilabel:`st` column holds the status of the file, defined
by Mercurial's status command, one of 'MARD?IC'.
3) The :guilabel:`ms` column holds the merge state of the file,
defined by Mercurial's resolve command, one of ' RU'. See the
merge section below.
4) The canonical path of the file (relative to the repository root)
Below the file list are checkboxes that toggle the display of the
various classes of files {modified, added, removed, deleted, unknown,
clean, ignored}. These check boxes will be disabled if the commit tool
was given a specific set of files and/or directories.
*Removed* means a revisioned file has been marked as removed. *Deleted*
means a revisioned file is missing but Mercurial has not been told to
quit tracking that file. For instance, if you rename a revisioned file
in the explorer, the original filename will show up as deleted and the
new filename will show up as unknown. By right-clicking on the new
filename you can bring up the rename guessing dialog which can discover
the rename by comparing file contents and mark the old file as removed
and the new file as added while recording the whole operation as a
rename.
*Unknown* files are not tracked by Mercurial, but they also do not match
any ignore filters you have configured. Unknown files are shown by
default because they are usually files that need to be added to revision
control. It is recommended that you keep your ignore filters up to date
to ensure that is the case. The context menu of unknown files has an
option open the ignore pattern tool.
*Clean* files are tracked files that have not been modified, while
*Ignored* files are untracked files that match a configured ignore
pattern. Neither of those file types are shown by default, unless a the
user includes such a file in a selection (explorer) or provides the file
on the command line.
Change Selection
----------------
So what does it mean when we say the commit button will commit the
selected diffs in checked files? Simple, the native TortoiseHg commit
tool supports change selection instrinsically in the diff browser. This
means that all of the changes you make to versioned files can be
individually selected to be included in the commit or left out of the
commit (but left in the working directory). Fans of darcs or
Mercurial's record extension will recognize this immediately.
When is this necessary?
^^^^^^^^^^^^^^^^^^^^^^^
When you have more than a single coherent change in your source code and
you would like to commit your changes piecemeal. This can often be
accomplished by filtering the list of files in each commit, but there
will be times when your changes intermingle in the same set of files and
that is when this change selection feature becomes indespensable.
How does it work?
^^^^^^^^^^^^^^^^^
By double-clicking on individual change hunks in the diff panel.
*Technically, any action which activates a change hunk row will toggle
it's selection status. The spacebar will also work.* When a hunk is
unselected, the syntax highlighting of the diff is disabled and the
background is turned gray. At the same time, the file's diff header is
updated to show the current selection state, the selected hunk count and
changed lines will be updated. Toggle the hunk a second time to reselect
it for inclusion in your commit.
When a file is partially selected for commit, it's icon is changed from
a checkbox to a radio button. At a glance at the file list, you should
be able to find which files are entirely included in the commit,
partially included, or excluded entirely.
What happens at commit time?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The short answer is that the selected hunks in checked files are
committed to the repository and the unselected changes are left in your
working directory for the next commit.
The long answer is a little more complicated. What happens behind the
scenes is that the files which are partially selected are backed up in a
safe location, reverted to their last revisioned state, have their
selected change hunks applied back to them, committed, and then finally
recovered from backup (thus placing the rejected change hunks back into
the working copy). Files which are not partially selected avoid the
entire *backup, revert, patch, commit, recover* round trip and instead
are committed in place.
This longer answer is only interesting when something goes wrong, which
on Windows unfortunately has a probability greater than 0. If some
program (virus checker, compiler) locks your file in the middle of this
process you may see an error about a failed patch. These errors are
recoverable. Delete any new :file:`.rej` files and try the commit again.
Keyboard navigation
-------------------
:kbd:`Ctrl-Enter`
will trigger the commit
:kbd:`Ctrl-C`
In the diff panel will copy the currently highlighted (not selected,
but highlighted) diff hunks to the clipboard. These can be pasted
into a text buffer to generate any arbitrary patch based from the
changes in your working directory.
The code which copies the hunks to the clipboard is intelligent about
diff headers. The clipboard contents will always be a valid patch.
File Context Menus
------------------
By right clicking on a file in the file list, you will get a context
menu of commands that are applicable to the selected file. If multiple
files are selected, the context menu only applies to the first selected
file.
If you have configured a visual editor (in
:menuselection:`Global Settings --> TortoiseHg --> Visual Editor`)
this includes an option to open the file in your editor.
For unknown **?** files, the context menu will allow you to detect
renames (if you think the unknown file is a copy or rename of a
revisioned file) or to configure the repository's ignore filter (if the
unknown file should never be revisioned and you want Mercurial to ignore
it).
Merging
-------
The commit tool has a special mode when it is opened in a repository
that is in a merged state (technically, this means the current working
directory has two parent revisions). The file list has no checkboxes and
the diff pane does not allow selections. The commit 'manifest' is
essentially immutable, since you must commit the entire working
directory after a merge.
The merge state *ms* column is especially useful in this mode. Files
that are marked with *R* are files where Mercurial and/or the user have
successfully merged (resolved) changes from both branches. Files that
are marked with *U* have unresolved changes. You can use the *resolve*
context menu option to restart the merge for that file, or you can use
the *edit* context menu option to resolve the conflict by hand. When the
conflict has been resolved, you use the *mark resolved* context menu
option, which changes the file's merge state to *R*.
Mercurial will not allow you to commit a merge if any files have
unresolved *U* merge states.
For your reference, *local* is the revision you had checked out when you
started the merge and *other* is the revision you merged with.
To undo a failed merge attempt, you must tell Mercurial to remove the
second parent from your working directory. This usually means
performing a clean update of the first parent. The merge tool has an
:guilabel:`Undo` button which does exactly that. The recovery tool also
has a :guilabel:`Clean` button that does the same thing.
Once you have your working directory back at one parent revision, you
may start the merge process again.
Commit Message Pane
-------------------
If your project has guidelines for commit message format, you can
configure those in the settings tool. The commit tool will enforce this
policy at commit time, and also has the ability to apply the policy to
the current message.
The commit message pane has special context menu options:
:guilabel:`Paste Filenames`:
Pastes checked filenames into the commit message at the cursor.
:guilabel:`Apply Format`:
Apply configured message wrap policy to current message.
:guilabel:`Configure Format`:
Opens the settings dialog to the :guilabel:`Commit` tab.
MQ patches
----------
Many advanced Mercurial users use the MQ extension to manage a patch
queue. TortoiseHg does not offer much in the way of support for MQ, but
the commit tool will at least recognize when a patch is applied. When a
patch is applied, the usual commit command will not work, so the commit
tool enters *patch refresh* mode. The title bar will say "refreshing
patch *patchname*" and the patch comment will appear in the commit
message pane.
The commit tool will present the entire contents of the top patch
including any changes that are in your working directory (un-refreshed
changes). This is essentially what the qdiff command would show you.
There is, in fact, no way to get just the working copy diffs beyond
running :command:`hg diff` on the command line. The reason the dialog
operates in this mode is that it allow you to use the integrated change
selection features to move changes into or out of the top patch. You can
move entire files or single changes in or out of the patch.
The :guilabel:`Commit` button, which has been renamed :guilabel:`QRefresh`
in this context, it will refresh the top patch with just the changes you
have selected (including the patch description). This may be a bit
confusing at first because the changes you leave out of the patch are
still going to be in the working directory after the refresh, so it will
look like nothing has changed.
So, in summary, using MQ with TortoiseHg is still almost entirely a
command line operation, but you can use :command:`hgtk ci` to refresh your
patches and take advantage of our excellent change selection support.
QNew Mode
---------
Newly added in 0.8, the commit tool can be used to create a new patch
for your patch queue. If you have the MQ extension enabled, a text
entry will be inserted between the branch maintenance button and the
message history drop-down box. If you enter a filename in this entry
the commit tool will switch out of *commit* or *qrefresh* mode into
*qnew* mode. In *qnew* mode, the commit tool shows only working
directory modifications (the changes that would typically get added to a
new patch by :command:`hg qnew -f`). The :guilabel:`Commit` button will
change into a :guilabel:`QNew` button as well, to make the mode switch
more obvious.
When the :guilabel:`QNew` button is pressed, the selected change hunks
are written into a new patch (given the filename you specified), and the
dialog is refreshed. At refresh, the commit tool will obviously switch
to *qrefresh* mode since there will now be at least one applied patch.
You may give the new patch a commit message at the initial *qnew* event,
or you can do it now by using the *qrefresh* feature.
If you left change hunks out of the new patch, they will appear to be in
the new patch anyway because of the way *qrefresh* mode shows the sum of
both the top patch and the working directory changes. If you enter a
new patch name again, and switch the commit tool into *qnew* mode again,
you will see the changes that you left in the working directory.
Configurables
-------------
:menuselection:`Commit --> Username`
Sets username associated with your commits (see :doc:`quick`)
:menuselection:`Commit --> External Tool`
Allows you to select Qct as the your commit tool [DEPRECATED]
:menuselection:`Commit --> Summary Line Length`
Configures a 'policy' limit for summary lines
:menuselection:`Commit --> Message Line Length`
Configures a 'policy' limit for message lines
:menuselection:`TortoiseHg --> Bottom Diffs`
Toggles diff pane from left to below file list
:menuselection:`TortoiseHg --> Max Diff Size`
Configures the diff size limit
External tool configuration is deprecated and will be removed in 0.9
From command line
-----------------
The commit tool can be started from command line::
hgtk commit [OPTIONS] [FILE]...
aliases: ci
commit tool
options:
-u --user record user as committer
-d --date record datecode as commit date
use "hgtk -v help commit" to show global options
For a quick help on the format of date type::
hg help dates
Changes since 0.7
-----------------
* The :guilabel:`Show Diff` button has been removed. Diffs are always shown.
* The commit tool no longer shows all diffs at startup. Only the first
currently selected file is shown.
* Added support for closing a named branch
* The commit tool is now launchable from the merge dialog
* The message pane context menu now has options for inserting selected
filenames, and configuring/applying a layout format.
* :guilabel:`Ctrl-O` keyboard accelerator for triggering commit has been
replaced with :guilabel:`Ctrl-Enter` accelerator which is common to
many THG dialogs
* Support for two-parent state (merging) has been improved, especially
the file context menus.
* There is now a limit on the size of files that will be diffed by the commit
and changelog tools. Files above this size will only show a message
indicating why the file was not diffed. This limit (default: 1MB) is
configurable (per-repository if necessary) via the settings dialog
:menuselection:`TortoiseHg --> Max Diff Size`.
* You can specify the commiter and date via the command line: see
:command:`hgtk commit -h` for details
* The :file:`qct.py` extension file is no longer bundled. It must be
downloaded separately if you wish to use Qct.
.. vim: noet ts=4
|
Loading...