See what's in a stash without applying it
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.
In the context of software development, particularly when dealing with version control systems like Git, "stashing" is a common method used to temporarily save changes in a working directory. This is particularly useful when you need to switch contexts without committing unfinished work to a branch. However, a frequent requirement is to inspect the contents of a stash before applying it, ensuring that the changes are precisely what you expect. This article provides a technical guide on how to achieve this, specifically in Git, along with relevant examples and details.
Understanding Git Stash
In Git, a stash is a mechanism to shelve (stash) changes in your working directory and index. This allows developers to switch branches or perform other operations without needing to commit unfinished work.
When you apply a stash with git stash apply, it changes your working directory with the modifications stored in the stash. Sometimes, this might lead to merge conflicts or unexpected behavior if you aren't entirely sure what those changes are. Hence, inspecting a stash before applying it is a valuable safeguard.
Inspecting a Stash Without Applying
Listing All Stashes
To begin with, you can list all your available stashes using the command:
This command will output a list of stashes with identifiers in the form stash@{index}. Each stash is accompanied by a brief message describing the changes (the commit's comment/message at the time of stashing).
Viewing the Contents of a Stash
To inspect a specific stash, use the git stash show command. This will show you a summary of changes within a stash:
Here, stash@{index} represents the specific stash you wish to inspect. This displays a summary of changes, similar to git diff --summary, showing which files were altered but not the detailed changes within those files.
Viewing Detailed Differences
For a detailed view of the changes contained in the stash, you can enhance the git stash show command with the -p (patch) flag:
Adding the -p flag generates a diff output, akin to git diff, showing line-by-line changes, additions, and deletions for each file involved in the stash. This enables thorough examination without applying the stash.
Annotated Example
Consider a simple example where a file, example.txt, has been modified and stashed. You haven't yet decided if these changes should be reintroduced into your working directory.
- List the current stashes:
- View the summary of the stash's changes:
Here we see that example.txt was modified, with 4 lines affected.
- View the detailed diff of the stash:
This detailed view tells you exactly what changes were made to example.txt in the stash, allowing for precise inspection.
Summary Table
Below is a summary table highlighting commands associated with inspecting a stash:
| Action | Command | Description |
| List all stashes | git stash list | List all stashes with identifier and descriptions. |
| Show stash summary | git stash show stash@{index} | Summarize changes in terms of affected files. |
| Show stash detailed changes | git stash show -p stash@{index} | Display detailed changes like a diff for inspection. |
Conclusion
Seeing what's in a stash without applying it is an essential skill for software developers using Git. This ability to inspect stashed changes allows you to manage your development workflow better and ensures that reintroducing changes into a working directory doesn’t lead to unforeseen conflicts. By employing commands like git stash show with its different flags, developers can have greater control over their code changes, leading to more efficient and error-free software development.
Related reading
- Selectively revert or checkout changes to a file in Git?
- Set up git to pull and push all branches
- Set Visual Studio Code to be global Git editor on OSX
- setting tabwidth to 4 in git show / git diff
- Setting up and using Meld as your Git difftool and mergetool
- Should a repository interface expose a clear() method to clear the cache of the implementation?
- Should composer.lock be committed to version control?
- Should Gemfile.lock be included in .gitignore?
.png&w=3840&q=75)
Tackling System Design Interview Problems
A short course that equips you with the skills to approach system design interviews methodically.
Start the free courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.