I believe this was the target result (b remains modified, a/* files are back, a/c is not recreated). No changes added to commit (use "git add" and/or "git commit -a") This gets you to a point where the last part of your script will output this: After checkout: Git stash drop #clean up the stash (optional) Git stash -keep-index #stash anything that isn't added Git add b #add the directory you want to keep
RESET SUB DIRECTORY TO MASTER GIT HOW TO
# How to make files a/* reappear without changing b and without recreating a/c? In your example, you would stash the b directory, then reset everything else. As you mentioned, stash doesn't accept a path directly, but it can still be used to keep a specific path with the -keep-index flag. You can use it like this: git reset-checkout 451a9a4 - path/to/directoryĪ reset will normally change everything, but you can use git stash to pick what you want to keep. Since this command fairly long and I plan on using it frequently, I have set up an alias for it which I named reset-checkout: git config -global alias.reset-checkout '!f() f' The fact that git diff takes a path argument allows you to limit this effect to a specific file or directory. Basically, this means that it makes the contents of the index match the contents of the revision you specified. This works by finding the diff between the target commit and the index, then applying that diff in reverse to the working directory and index. Git diff -cached commit - subdir | git apply -R -index So instead, I have begun using the following command: However, when you wish to reset a directory to a revision other than HEAD, that solution has a significant problem: it doesn't remove files which were deleted in the target revision. Note: With git checkout -overlay HEAD - (Git 2.22, Q1 2019), files that appear in the index and working tree, but not in are removed, to make them match exactly.īut that checkout can respect a git update-index -skip-worktree (for those directories you want to ignore), as mentioned in " Why do excluded files keep reappearing in my git sparse checkout?".įor the case of simply discarding changes, the git checkout - path/ or git checkout HEAD - path/ commands suggested by other answers work great. If you have extra files in the working tree which don't exist in HEAD, a git checkout HEAD - won't remove them. git checkout HEAD - does a hard reset for a path, replacing both the index and the working tree with the version from the HEAD commit.Īs answered by Ajedi32, both checkout forms don't remove files which were deleted in the target revision.git checkout - doesn't do a hard reset: it replaces the working tree contents with the staged contents.Note (as commented by Dan Fabulich) that: That would replace both the index and working tree with HEAD content, like an reset -hard would, but for a specific path. With Git 2.23 (August 2019), you have the new command git restore (also presented here) git restore -source=HEAD -staged -worktree - aDirectory
EDIT: And I also don't "know" b, or which other directories reside on the same level as a. Note that I do not want to explicitly restore a/a and a/b, I only "know" a and want to restore everything below. Insert the proper command below the How to make files comment - the current command will restore the file a/c/ac which is supposed to be excluded by the sparse checkout. The script below illustrates the problem. What is the proper Git command for this operation?
RESET SUB DIRECTORY TO MASTER GIT PATCH
I can reverse-patch the current state using git diff subdir | patch -p1 -R, but this is a rather weird way of doing this. Īgain: Why git can't do hard/soft resets by path? There is git reset -hard, but it won't let me do it for a subdirectory: > git reset -hard. adds directories excluded by sparse checkout Imagine the following use case: I want to get rid of all changes in a specific subdirectory of my Git working tree, leaving all other subdirectories intact. UPDATE: This will work more intuitively as of Git 1.8.3, see my own answer. UPDATE²: With Git 2.23 (August 2019), there's a new command git restore that does this, see the accepted answer.
0 kommentar(er)
