<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sect1 SYSTEM "../../../dtd/dblite.dtd">
<sect1 id="tgit-dug-stash">
	<?dbhh topicname="HIDD_STASH"?>
	<title>Stash Changes</title>
	<indexterm>
		<primary>stash</primary>
	</indexterm>
	<para>
		Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else.
		The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command.
	</para>
	<para>
		Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time (even on a different branch).
	</para>
	<tip>
		<para>
			There is a similar function in TortoiseGit called changelists (<xref linkend="tgit-dug-changelists"/>) which can be used to structure commits.
		</para>
	</tip>
	<para>
		When you want to record the current state of the working directory and the index,
		but want to go back to a clean working directory,
		<action>right click</action> on a folder to pop up the context menu and then select
		the command
		<menuchoice>
			<guimenu>TortoiseGit</guimenu>
			<guimenuitem>Stash changes</guimenuitem>
		</menuchoice>
		A dialog will pop up where you can optionally enter a message for this state:
		<figure id="tgit-dug-stash-dia-1">
			<title>Stash changes dialog</title>
			<graphic fileref="../images/stash.png"/>
		</figure>
		You can also select <guilabel>include untracked</guilabel>, to stash untracked files away, too.
		To stash all files away, including ignored files in addition to the untracked files, select <guilabel>--all</guilabel>.
	</para>
	<para>
		When TortoiseGit detects that a stashed changes exist, the context menu will be extended:
		<figure id="tgit-dug-stash-dia-2">
			<title>(un)stash options</title>
			<graphic fileref="../images/ContextMenuStash.png"/>
		</figure>
		The stash is implemented as a stack. <guimenuitem>Stash Apply</guimenuitem> will apply the changes of the latest stash
		to your working tree. <guimenuitem>Stash Pop</guimenuitem> does the same, but will remove the latest stash from the stack
		after applying it. <guimenuitem>Stash changes</guimenuitem> is still possible and will stash the current changes of the working
		copy to the top of the stack. <guimenuitem>Stash List</guimenuitem> provides an overview of all the whole stash stack. You
		can also remove and view the stashed changes there (similarly to the <xref linkend="tgit-dug-showlog"/> and <xref linkend="tgit-dug-reflog"/>).
	</para>
	<important>
		<title>Conflicts</title>
		<para>
			Although major merge work is done by git automatically applying a stash, a conflict may happen during cherry-picking (i.e., a file was modified in your current branch and also in the stash),
			please see <xref linkend="tgit-dug-conflicts"/> on how to resolve conflicts.
		</para>
		<para>
			Please note, that "REMOTE"/"theirs" in the conflict editor refers to the to be merged stash and "LOCAL"/"mine" to your version in the working tree before you applied the stash.
		</para>
	</important>
	<para>
		You can find more information at <gitdoclink cmd="git-stash" section="1"/>.
	</para>
</sect1>
