path: root/
AgeCommit message (Collapse)Author
2020-03-05stash: remove the stash.useBuiltin settingThomas Gummerer
Remove the stash.useBuiltin setting which was added as an escape hatch to disable the builtin version of stash first released with Git 2.22. Carrying the legacy version is a maintenance burden, and has in fact become out of date failing a test since the 2.23 release, without anyone noticing until now. So users would be getting a hint to fall back to a potentially buggy version of the tool. We used to shell out to git config to get the useBuiltin configuration to avoid changing any global state before spawning legacy-stash. However that is no longer necessary, so just use the 'git_config' function to get the setting instead. Similar to what we've done in d03ebd411c ("rebase: remove the rebase.useBuiltin setting", 2019-03-18), where we remove the corresponding setting for rebase, we leave the documentation in place, so people can refer back to it when searching for it online, and so we can refer to it in the commit message. Signed-off-by: Thomas Gummerer <> Signed-off-by: Junio C Hamano <>
2020-02-05Merge branch 'js/patch-mode-in-others-in-c'Junio C Hamano
The effort to move "git-add--interactive" to C continues. * js/patch-mode-in-others-in-c: commit --interactive: make it work with the built-in `add -i` built-in add -p: implement the "worktree" patch modes built-in add -p: implement the "checkout" patch modes built-in stash: use the built-in `git add -p` if so configured legacy stash -p: respect the add.interactive.usebuiltin setting built-in add -p: implement the "stash" and "reset" patch modes built-in add -p: prepare for patch modes other than "stage"
2019-12-22legacy stash -p: respect the add.interactive.usebuiltin settingJohannes Schindelin
As `git add` traditionally did not expose the `--patch=<mode>` modes via command-line options, the scripted version of `git stash` had to call `git add--interactive` directly. But this prevents the built-in `add -p` from kicking in, as `add--interactive` is the scripted version (which does not have a "fall-back" to the built-in version). So let's introduce support for internal switch for `git add` that the scripted `git stash` can use to call the appropriate backend (scripted or built-in, depending on `add.interactive.useBuiltin`). Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-11-10Merge branch 'js/update-index-ignore-removal-for-skip-worktree'Junio C Hamano
"git stash save" in a working tree that is sparsely checked out mistakenly removed paths that are outside the area of interest. * js/update-index-ignore-removal-for-skip-worktree: stash: handle staged changes in skip-worktree files correctly update-index: optionally leave skip-worktree entries alone
2019-11-02stash: handle staged changes in skip-worktree files correctlyJohannes Schindelin
When calling `git stash` while changes were staged for files that are marked with the `skip-worktree` bit (e.g. files that are excluded in a sparse checkout), the files are recorded as _deleted_ instead. The reason is that `git stash` tries to construct the tree reflecting the worktree essentially by copying the index to a temporary one and then updating the files from the worktree. Crucially, it calls `git diff-index` to update also those files that are in the HEAD but have been unstaged in the index. However, when the temporary index is updated via `git update-index --add --remove`, skip-worktree entries mark the files as deleted by mistake. Let's use the newly-introduced `--ignore-skip-worktree-entries` option of `git update-index` to prevent exactly this from happening. Note that the regression test case deliberately avoids replicating the scenario described above and instead tries to recreate just the symptom. Reported by Dan Thompson. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-10-15stash: avoid recursive hard reset on submodulesJakob Jarmar
git stash push does not recursively stash submodules, but if submodule.recurse is set, it may recursively reset --hard them. Having only the destructive action recurse is likely to be surprising behaviour, and unlikely to be desirable, so the easiest fix should be to ensure that the call to git reset --hard never recurses into submodules. This matches the behavior of check_changes_tracked_files, which ignores submodules. Signed-off-by: Jakob Jarmar <> Signed-off-by: Junio C Hamano <>
2019-03-08legacy stash: fix "rudimentary backport of -q"Johannes Schindelin
When this developer backported support for `--quiet` to the scripted version of `git stash` in 80590055ea (stash: optionally use the scripted version again, 2018-12-20), it looked like a sane choice to use `eval` to execute the command line passed in via the parameter list of `maybe_quiet`. However, that is not what we should have done, as that command-line was already in the correct shape. This can be seen very clearly when passing arguments with special characters, like git stash -- ':(glob)**/*.txt' Since this is exactly what we want to test in the next commit (where we fix this very incantation with the built-in stash), let's fix the legacy scripted version of `git stash` first. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-03-07stash: optionally use the scripted version againJohannes Schindelin
We recently converted the `git stash` command from Unix shell scripts to builtins. Let's end users a way out when they discover a bug in the builtin command: `stash.useBuiltin`. As the file name `git-stash` is already in use, let's rename the scripted backend to `git-legacy-stash`. To make the test suite pass with `stash.useBuiltin=false`, this commit also backports rudimentary support for `-q` (but only *just* enough to appease the test suite), and adds a super-ugly hack to force exit code 129 for `git stash -h`. Signed-off-by: Johannes Schindelin <> Signed-off-by: Thomas Gummerer <> Signed-off-by: Junio C Hamano <>