On Tue, Sep 11, 2007 at 12:30:33AM +0200, David Kastrup wrote:

quoted text
> 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?

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html