On Tue, Sep 11, 2007 at 12:30:33AM +0200, David Kastrup wrote:
> It's the equivalent of not moving done work from the "IN" pile. At
> some point of time you don't remember which of the stashes you already
> did fold back, and which you didn't.
>
> So it is quite natural to expect a stash to be gone after applying it.
> The first surprise is that it is still there.
Then perhaps the right solution is to move it to a "DONE" pile (rather
than leaving it on "IN" or deleting it entirely).
It _should_ be a simple matter of just removing the N'th line of the
reflog and appending it to an 'applied-stash' reflog. However, there are
a few problems:
- Finding the line number is non-trivial. git-stash never actually
parses stash@{1}, but hands it off to rev-parse. So it is legal to
say stash@{10.minutes.ago}.
- When you apply a stash, there might be conflicts. What should the
semantics be in that case? If we move the stash to a 'DONE' pile (or
delete it), then conflicts become a bit clunky:
git-stash apply stash@{0}
# oops, conflicts
git-reset --hard
hack hack hack
git-commit
git-stash apply stash@{0}
# oops, we just applied a different stash
If we wait until conflicts are resolved, then we are increasing the
statefulness required. When do we mark the stash as successfully
applied? Do we handle all cases where you "git-reset" to abort?
> Is there _anybody_ (short of the git-stash author himself) who has
> _not_ experienced _both_ surprises?
I think it is "herself" in this case. :)
-Peff
-
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
