Re: [PATCH] git-stash: add flag to skip "git reset --hard"
- From
- Tom Anderson <thomasanderson@google.com>
- Date
- May 2, 2016, 19:13 UTC
- Message-ID
- <5727A6DF.5020204@google.com>
- In-Reply-To
- <xmqqeg9kti6x.fsf@gitster.mtv.corp.google.com>
On 05/02/2016 11:42 AM, Junio C Hamano wrote:
Show 17 quoted lines
> Tom Anderson <thomasanderson@google.com> writes: > >> @@ -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 themShow 9 quoted lines
> > 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?
Show 5 quoted lines
> 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?