-
Notifications
You must be signed in to change notification settings - Fork 142
stash: add --include-untracked support to git stash create #1892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Welcome to GitGitGadgetHi @SBhojani, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that either:
You can CC potential reviewers by adding a footer to the PR description with the following syntax:
NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel
Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):
To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join [email protected], where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
Invalid author email in e33d91c: "[email protected]" |
e33d91c
to
95adfb8
Compare
There are issues in commit 95adfb8: |
95adfb8
to
4d819d7
Compare
builtin/stash.c
Outdated
if (!check_changes_tracked_files(&ps)) | ||
return 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SBhojani I am fairly certain that this is needed, and that this accidental removal is the underlying root cause for the CI build to fail.
This should fix it:
diff --git a/builtin/stash.c b/builtin/stash.c
index e9eb15b53407..34828d1e2209 100644
--- a/builtin/stash.c
+++ b/builtin/stash.c
@@ -1524,6 +1524,8 @@ static int create_stash(int argc, const char **argv, const char *prefix,
strbuf_join_argv(&stash_msg_buf, argc, argv, ' ');
memset(&ps, 0, sizeof(ps));
+ if (!check_changes_tracked_files(&ps))
+ return 0;
ret = do_create_stash(&ps, &stash_msg_buf, include_untracked, 0, 0, &info,
NULL, 0);
The `git stash create` command now supports the `--include-untracked` flag, allowing users to include untracked files in the stash entry. This brings parity with `git stash push`, which already supports this option. Previously, `git stash create` would only stash tracked changes. With this change, users can optionally include untracked files by specifying `--include-untracked`. The implementation involves parsing the new option in `create_stash` and passing it to `do_create_stash`, which handles the creation of the stash entry. The early check for tracked changes was removed to allow stashing when only untracked files are present. Test cases were added to `t3903-stash.sh` to ensure the correct behavior, and the documentation was updated accordingly. Signed-off-by: SBhojani <[email protected]>
4d819d7
to
d5a62cb
Compare
/* Starting with argv[1], since argv[0] is "create" */ | ||
strbuf_join_argv(&stash_msg_buf, argc - 1, ++argv, ' '); | ||
argc = parse_options(argc, argv, prefix, options, git_stash_create_usage, 0); | ||
|
||
strbuf_join_argv(&stash_msg_buf, argc, argv, ' '); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't we want the --include-untracked
option to be included in the message? In other words:
/* Starting with argv[1], since argv[0] is "create" */
- strbuf_join_argv(&stash_msg_buf, argc - 1, ++argv, ' ');
+ strbuf_join_argv(&stash_msg_buf, argc - 1, argv + 1, ' ');
@@ -632,6 +632,47 @@ test_expect_success 'stash create - no changes' ' | |||
test_must_be_empty actual | |||
' | |||
|
|||
test_expect_success 'stash create with --include-untracked' ' | |||
git init repo && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should not be any need to initialize a repository; When test_expect_success
' code runs, it does so in a Git worktree that was prepared specifically for testing.
echo committed >file1 && | ||
git add file1 && | ||
git commit -m "initial commit" && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be more concise to run test_commit file1
...
Also, wouldn't it be possible to reuse what had already been set up by an earlier test case?
/allow |
User SBhojani is now allowed to use GitGitGadget. WARNING: SBhojani has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use. |
grep "parent" stash_commit | wc -l >parent_count && | ||
echo 3 >expect && | ||
test_cmp expect parent_count && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SBhojani As pointed out by the test failures, you will want to use grep parent stash_commit >parents && test_line_count = 3 parents
instead (see the documentation of test_line_count
; wc -l
's output is not strictly portable).
This is a single-commit pull request, and the commit message already describes the changes.
I just want to add context for where I felt the need for this. While working on a logical single commit task, my working tree is often in a state where certain changes are staged and others are not. I use this staging strategy as a conceptual model of which changes I intend to mostly keep as they are and which I intend to change, rewrite, refactor, discard, or not commit. Some of the changes in the latter category might be new untracked files. Now, I often use (my git GUI tool's equivalent of)
git stash --include-untracked
followed bygit stash apply
to take a snapshot of these changes to be able to come back to the state if I mess things up too much from that point on. Doing that results in the working directory being cleaned momentarily and then being repopulated again. My development tools often detect this as the files having been changed and then prompt me to reload them or cause rebuilds and so on.git stash store $(git stash create)
has the nice feature that it doesn't touch the working directory, but it was missing the ability to also stash untracked files. This change fixes that.