Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes:
> The "save" subcommand usually removes the changes it stashed from the
> index and the work tree. Existing --keep-index option however keeps the
> changes to the index. This new option keeps the changes made to both the
> index and the work tree.
I saw --no-reset mentioned earlier but probably this is a more consistent
name for the feature.
But I somewhat doubt if this line of change is a good idea to begin with.
The earlier --keep-index feature had a clear definition of what workflow
benefits from it, and also made it clear that the workflow it helped was a
good workflow. You build what you would consider a good change in the
index bit by bit, but you would want a final test of the whole tree,
without the changes that you are still not sure and are not in the index.
Before --keep-index, we did not have a good way to do so.
This one, the "snapshot", and various other related topics, are quite
different. The workflow the --keep (and for that matter, "snapshot")
would support I can think of does not sound a very good one we would want
to recommend (--untracked is a different issue; I haven't formed an
opinion).
You build on a branch, but you are forever in the state of indecision, and
instead of committing, you keep saying "save --keep" number of times to
leave a checkpoint on your stash. After number of iterations, you may
have many stashes in "git stash list", but what you can do with them is
"git reset --hard && git stash apply stash@{$n}" to go back to any of the
state, but that is about it.
If the topic you are working on is that involved, and if you are afraid of
contaminating the branch you started off of (which is groundless given the
nature of git that is distributed --- the act of committing is explicitly
disconnected from the act of publishing), then you are much better off
forking the original branch to another branch on which you do your own
work, and make normal commits to checkpoint your states. That way, you
can use the usual history rewriting tools such as "rebase --interactive"
and "merge --squash" to finish it off once you reached a good state.
All talks about using stash --no-rest and snapshot share this problem. By
not making regular commits, you are denying yourself the rich set of tools
git offers you to use on regular commits and the ancestry chains between
them, and nobody explained what the benefits of not using normal commits
on normal branches are, nor how the inconveniences from this aversion to
branches forces you are justified by those unexplained benefits.
This topic won't go beyond 'next' during this round because it started way
after -rc0 was tagged. It is not urgent to decide what will happen to the
recent "snapshot" related topics, and we have plenty of time to toss ideas
around, but currently I have to say that I am not very enthused about any
of the causes mentioned in various discussion threads.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
