I need to stash a set of changes that includes a new file - without deleting ignored directories.
So I tried this:
git add --intent-to-add myNewFile.txt
git stash
The result was:
error: Entry 'myNewFile.txt' not uptodate. Cannot merge.
Cannot save the current worktree state
How can I stash the modified files plus one or more selected new files, but not affect any other files or directories (in particular those in .gitignore
)?
(This is not a duplicate of how can I git stash a specific file? because that question is how to stash a file that has previously been added. My problem is to stash a file that has not yet been added.)
The stash entry is kept in case you need it again. There's no magic remedy for such merge conflicts. The only option for developers is to edit the file by hand and keep what they want and dispose of what they don't want. Once they merge and save the file, they will have effectively resolved the git stash conflict.
Run git add first. I just discovered that if your uncommitted changes are added to the index (i.e. "staged", using git add ... ), then git stash apply (and, presumably, git stash pop ) will actually do a proper merge.
You can reapply stashed changes with the commands git stash apply and git stash pop . Both commands reapply the changes stashed in the latest stash (that is, stash@{0} ).
UPDATE - further testing shows that a regular commit, ironically, works relatively well. Speculative wording revised accordingly...
The problem seems to be with how git handles an index entry that has no content. Although it will commit around the placeholder entry, something about it isn't acceptable to stash
. (I can think of multiple potential challenges. The most obvious is that the stash is made of commits - in the database - and there's no way to represent "plan to commit" in that context. The error message suggests the fatal problem is elsewhere, probably to do with how the WIP commit is assembled.)
It may be that you could get by with just git add
ing the file (without the -N
option). The only reason not to, would be if you have other staged changes and don't want the state of that file to get mixed up in those other changes.
A compromise in that case would be to add an empty version of the file (so that your placeholder that keeps the file from being un-tracked has empty content rather than being an entry without content). Then you can put the real file at the path, and it will be "modified" rather than "untracked", so you can stash without the problematic -u
option.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With