Tom Anderson [off-list ref] writes:
quoted hunk
@@ -61,6 +61,9 @@ stashed and then cleaned up with `git clean`,
leaving the working directory
in a very clean state. If the `--all` option is used instead then the
ignored files are stashed and cleaned in addition to the untracked files.
+
+If the `--no-reset` option is used, `git reset --hard` is skipped and the
+`--[no-]keep-index`, `--include-untracked`, and `--all` flags are ignored.
++
I am afraid that a reader who does not read git-stash.sh script
would not know what you are talking about. They do not know (or
particularly care) where "git reset --hard", how often and for what
purpose. They can tell that this option affects only "save",
because that is where it is described, but they would not know what
it means to "skip reset --hard", other than that they cannot use the
three features listed there.
It is unclear what problem you are trying to solve from this text,
and the log message's mention of mtime and rebuilding makes it
sound like an X-Y problem.
It could very well be that what you are trying to implement makes
perfect sense and the new option is named with a stress on a wrong
aspect (i.e. named after what it uses to achieve things, rather than
saying what you are trying to achieve).
The workhorse used in "git stash save" (which is what you are
touching) is "git stash create", and that is only responsible for
recording a new stash entry without touch the working tree. Is that
what you are after, perhaps?
On 05/02/2016 11:42 AM, Junio C Hamano wrote:
Tom Anderson [off-list ref] writes:
quoted
@@ -61,6 +61,9 @@ stashed and then cleaned up with `git clean`,
leaving the working directory
in a very clean state. If the `--all` option is used instead then the
ignored files are stashed and cleaned in addition to the untracked files.
+
+If the `--no-reset` option is used, `git reset --hard` is skipped and the
+`--[no-]keep-index`, `--include-untracked`, and `--all` flags are ignored.
++
I am afraid that a reader who does not read git-stash.sh script
would not know what you are talking about. They do not know (or
particularly care) where "git reset --hard", how often and for what
purpose. They can tell that this option affects only "save",
because that is where it is described, but they would not know what
it means to "skip reset --hard", other than that they cannot use the
three features listed there.
The man page for git-stash unfortunately already makes a reference to
git reset --hard:
save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked]
[-a|--all] [-q|--quiet] [<message>]
Save your local modifications to a new stash, and run git reset
--hard to revert them
It is unclear what problem you are trying to solve from this text,
and the log message's mention of mtime and rebuilding makes it
sound like an X-Y problem.
It could very well be that what you are trying to implement makes
perfect sense and the new option is named with a stress on a wrong
aspect (i.e. named after what it uses to achieve things, rather than
saying what you are trying to achieve).
Perhaps it would be better to rename --no-reset to something more
appropriate?
The workhorse used in "git stash save" (which is what you are
touching) is "git stash create", and that is only responsible for
recording a new stash entry without touch the working tree. Is that
what you are after, perhaps?
Yes, but I like my stashes to be saved in the ref namespace. Maybe an
alternative if it's a bad idea to add this new flag to "git stash save" is
to add a new flag to "git stash create"? Or make a new git-stash command
entirely?