stash refuses to pop

stash refuses to pop

[Phillip Susi]

git stash refuses to apply a stash if it touches files that are 
modified.  Using stash -p to selectively stash some hunks of a file and 
then immediately trying to pop that stash causes this failure every 
time.  This seems incredibly  broken, and there does not seem to be a 
force switch.  How can you get the stash applied?

Re: stash refuses to pop

[Junio C Hamano]

Phillip Susi <psusi@ubuntu.com> writes:

> git stash refuses to apply a stash if it touches files that are
> modified.  Using stash -p to selectively stash some hunks of a file
> and then immediately trying to pop that stash causes this failure
> every time.

I think that is by design.

I do not use "stash -p" and personally, but I think its broken from the UI
point of view.  The point of "stash" is to clear your workspace to a
pristine state, do random things, and after you are done and cleared your
workspace again, apply it to come back to the original state or a state as
if you started your WIP from the updated clean-slate.

So probably the right way to use "stash -p" (if there were such a thing)
would be to stash away the remainder in a separate stash with another
"stash" without "-p" (which will clear your workspace to a pristine state)
and then pop the one you created with "stash -p", I think.

Re: stash refuses to pop

[Phillip Susi]

On 4/10/2012 2:05 PM, Junio C Hamano wrote:
> Phillip Susi<psusi@ubuntu.com>  writes:
>
>> git stash refuses to apply a stash if it touches files that are
>> modified.  Using stash -p to selectively stash some hunks of a file
>> and then immediately trying to pop that stash causes this failure
>> every time.
>
> I think that is by design.

Being able to push something that you can not pop seems to be broken 
design...

> I do not use "stash -p" and personally, but I think its broken from the UI
> point of view.  The point of "stash" is to clear your workspace to a
> pristine state, do random things, and after you are done and cleared your
> workspace again, apply it to come back to the original state or a state as
> if you started your WIP from the updated clean-slate.

Or temporarily undo some changes and come back to those changes later?

> So probably the right way to use "stash -p" (if there were such a thing)
> would be to stash away the remainder in a separate stash with another
> "stash" without "-p" (which will clear your workspace to a pristine state)
> and then pop the one you created with "stash -p", I think.

That would not get you back to the state you were in when you first 
stashed, but instead to a state where you have the first set of changes, 
but not the second ( which you then also can not pop due to the first 
changes being there ).

Re: stash refuses to pop

[Andrew Ardill]

On 11 April 2012 04:56, Phillip Susi <psusi@ubuntu.com> wrote:
> On 4/10/2012 2:05 PM, Junio C Hamano wrote:
>>
>> Phillip Susi<psusi@ubuntu.com>  writes:
>>
>>> git stash refuses to apply a stash if it touches files that are
>>> modified.  Using stash -p to selectively stash some hunks of a file
>>> and then immediately trying to pop that stash causes this failure
>>> every time.
>>
>>
>> I think that is by design.
>
>
> Being able to push something that you can not pop seems to be broken
> design...
>
>
>> I do not use "stash -p" and personally, but I think its broken from the UI
>> point of view.  The point of "stash" is to clear your workspace to a
>> pristine state, do random things, and after you are done and cleared your
>> workspace again, apply it to come back to the original state or a state as
>> if you started your WIP from the updated clean-slate.
>
>
> Or temporarily undo some changes and come back to those changes later?
>
>
>> So probably the right way to use "stash -p" (if there were such a thing)
>> would be to stash away the remainder in a separate stash with another
>> "stash" without "-p" (which will clear your workspace to a pristine state)
>> and then pop the one you created with "stash -p", I think.
>
>
> That would not get you back to the state you were in when you first stashed,
> but instead to a state where you have the first set of changes, but not the
> second ( which you then also can not pop due to the first changes being
> there ).

The first question, it would seem, is what should git do when there
are modified files present, and the user tries to pop a stash which
touches those files. The current behaviour is to reject the pop,
reasonable enough, though for what exact reason I am not sure
(potential merge issues, I assume).

The method you have described is just one way of coming on this
situation. The user could have
* stashed their work, modified some files and tried to pop
* partially stashed their work, and tried to pop
* partially stashed their work, modified some files and then tried to pop.

The options for dealing with this situation seem to be
1. Reject the pop outright
2. put the affected files into a merge conflict state
3. revert the file to the state they were at at the time of stash
4. reject those files that do not apply cleanly (but apply all others)
5. reject those hunks which do not apply cleanly (but apply all others)
6. provide an interactive pop session for choosing what to apply

I don't know if all of these are possible/feasible/reasonable.
1. possible by # git reset
2. default behaviour
3. is possible using # git stash branch <branchname> [<stash>]
4. 5. seems this might be possible, not sure of best method
6. this would be something like # git stash pop -p [<stash>], which I
think does not exist yet

I would like to see 6. implemented, but the behaviour seems very
reasonable at the moment.

Regards,

Andrew Ardill

Re: stash refuses to pop

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/10/2012 10:47 PM, Andrew Ardill wrote:
> The first question, it would seem, is what should git do when there
> are modified files present, and the user tries to pop a stash which
> touches those files. The current behaviour is to reject the pop,
> reasonable enough, though for what exact reason I am not sure
> (potential merge issues, I assume).

Since pop is the inverse of push, and merge is the inverse of a partial push, I would expect pop to perform a merge.

> The method you have described is just one way of coming on this
> situation. The user could have
> * stashed their work, modified some files and tried to pop
> * partially stashed their work, and tried to pop
> * partially stashed their work, modified some files and then tried to pop.

Yes, there are a number of ways you can get to the situation where you can not pop the stash.  How to resolve this is unclear from the results of the failed pop.  I finally ended up resolving it by committing the remaining changes, then popping the stash ( which performed the merge successfully ), and finally doing a git reset HEAD~1 to remove the temporary commit, but preserve the merged results.  This seemed like a good deal of unnecessary trouble.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPhPObAAoJEJrBOlT6nu75qwkH/jlWpu+yRIx9l8qsp4+MWB/I
FPfKku+LnUpRoegsmKMer1J59kriw8zJF8hujHUUp1RcCdfQBUJwCDZnNGEa/LRn
PNrceRHc3V92ImBBJHwLsOqr4IQa7O+PDG8Tuht6q6NwIxEu2ZycoxnThx7JoF/G
wsD5KA9yZmJKb+lptCNVVfgez4k6ESqnekx4Tsl8C5UOUXbra61SC6vG+igRnU2P
6V+QaYbHEmNNq3pLmebCty/wmzwHJc9oTA+wDawJwV5BhcgsKnUY0RhVMT86t1Qu
IbwqkFUJV9je1GZKEwklvbLnBx2js80yvEnPWpC3jt9j6gxRGAfaq/5NQnl7vQE=
=UEM3
-----END PGP SIGNATURE-----

Re: stash refuses to pop

[Johannes Sixt]

Am 4/10/2012 20:56, schrieb Phillip Susi:
> On 4/10/2012 2:05 PM, Junio C Hamano wrote:
>> Phillip Susi<psusi@ubuntu.com>  writes:
>>
>>> git stash refuses to apply a stash if it touches files that are
>>> modified.  Using stash -p to selectively stash some hunks of a file
>>> and then immediately trying to pop that stash causes this failure
>>> every time.
>>
>> I think that is by design.
> 
> Being able to push something that you can not pop seems to be broken
> design...

You are trying to abuse git-stash, but it does not cooperate because it
was not designed to be abused ;-) git-stash is not intended as a generic
push-and-pop-my-changes work horse.

The purpose of git-stash is that you can "move away"

- all of your changes to have a clean worktree or
- part of your changes to _create a clean worktree from the remaining
changes_.

That is, before you can think of applying a stash, you are expected to
have cleaned out your worktree.

-- Hannes

Re: stash refuses to pop

[Victor Engmark]

On Wed, Apr 11, 2012 at 4:47 AM, Andrew Ardill <andrew.ardill@gmail.com> wrote:
>
> On 11 April 2012 04:56, Phillip Susi <psusi@ubuntu.com> wrote:
> > On 4/10/2012 2:05 PM, Junio C Hamano wrote:
> >> So probably the right way to use "stash -p" (if there were such a thing)
> >> would be to stash away the remainder in a separate stash with another
> >> "stash" without "-p" (which will clear your workspace to a pristine state)
> >> and then pop the one you created with "stash -p", I think.
> >
> > That would not get you back to the state you were in when you first stashed,
> > but instead to a state where you have the first set of changes, but not the
> > second ( which you then also can not pop due to the first changes being
> > there ).
>
> The first question, it would seem, is what should git do when there
> are modified files present, and the user tries to pop a stash which
> touches those files. The current behaviour is to reject the pop,
> reasonable enough, though for what exact reason I am not sure
> (potential merge issues, I assume).
>
> The method you have described is just one way of coming on this
> situation. The user could have
> * stashed their work, modified some files and tried to pop
> * partially stashed their work, and tried to pop
> * partially stashed their work, modified some files and then tried to pop.
>
> The options for dealing with this situation seem to be
> 1. Reject the pop outright
> 2. put the affected files into a merge conflict state
> 3. revert the file to the state they were at at the time of stash
> 4. reject those files that do not apply cleanly (but apply all others)
> 5. reject those hunks which do not apply cleanly (but apply all others)
> 6. provide an interactive pop session for choosing what to apply

#2 seems like the most natural option, for the reason Phillip Susi
mentioned. But how about
7. Apply all hunks iff all of them can be applied cleanly
? That way pop would be an atomic operation. It might be easier to do
than 2, and even if 2 is implemented it would be nice to have a
--atomic or --dry-run option when you want to make sure not to end up
in a messy merge.

Cheers,
V

Re: stash refuses to pop

[Phillip Susi]

On 4/11/2012 1:58 AM, Johannes Sixt wrote:
> You are trying to abuse git-stash, but it does not cooperate because it
> was not designed to be abused ;-) git-stash is not intended as a generic
> push-and-pop-my-changes work horse.

In what way is using the documented -p switch abuse?

> The purpose of git-stash is that you can "move away"

Yes, and then move back.  That is why it is broken that you can not 
immediately move back after a stash -p.

> - all of your changes to have a clean worktree or
> - part of your changes to _create a clean worktree from the remaining
> changes_.
>
> That is, before you can think of applying a stash, you are expected to
> have cleaned out your worktree.

It is obvious that is the assumption that stash was originally made 
with, and it might make some sense if it always left the tree in a clean 
state, but it no longer makes sense given -p and how it can leave the 
tree in a not clean state.

This is clearly a case of the initial implementation being a bit lazy. 
pop already performs a type of merge, just on a whole file basis.  In 
other words, the pop leaves you with some files from before the pop, and 
some files that were modified by the pop.  It should do a proper merge 
instead of a lazy whole file merge.

Re: stash refuses to pop

[Johannes Sixt]

Am 4/11/2012 16:21, schrieb Phillip Susi:
> On 4/11/2012 1:58 AM, Johannes Sixt wrote:
>> You are trying to abuse git-stash, but it does not cooperate because it
>> was not designed to be abused ;-) git-stash is not intended as a generic
>> push-and-pop-my-changes work horse.
> 
> In what way is using the documented -p switch abuse?

It isn't.

>> The purpose of git-stash is that you can "move away"
> 
> Yes, and then move back.

This is abuse, if you haven't cleaned your worktree.

>> That is, before you can think of applying a stash, you are expected to
>> have cleaned out your worktree.
> 
> It is obvious that is the assumption that stash was originally made with,
> and it might make some sense if it always left the tree in a clean state,
> but it no longer makes sense given -p and how it can leave the tree in a
> not clean state.

You are misunderstanding. The intended workflow is:

  stash -p
  # ... test the remaining changes in isolation ...
  commit -a
  # now the worktree is clean
  stash pop

-- Hannes

Re: stash refuses to pop

[Andreas Krey]

On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote:
...
> Yes, there are a number of ways you can get to the situation where you can not pop the stash.  How to resolve this is unclear from the results of the failed pop.  I finally ended up resolving it by committing the remaining changes, then popping the stash ( which performed the merge successfully ), and finally doing a git reset HEAD~1 to remove the temporary commit, but preserve the merged results.  This seemed like a good deal of unnecessary trouble.

(Late to the game.) Actually, this is exactly what I would have proposed
to do. Git is a bit shy on performing a merge into a locally modified
file. I assumed so far that is because there is no way of aborting
such a merge (resetting to the state of local modifications before the
attempt). With the temporary commit you have a way of retrying the pop
merge if you lost your way in it.

And I think that is a good idea; I never liked the way in which a cvs/svn
update merged into locally modified files without a way to undo, and
thus forcing you to clean up the potential mess manually. (Ok, they leave
the old files lying arond, but that doesn't help rewinding the state.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: stash refuses to pop

[Jakub Narebski]

Andreas Krey <a.krey@gmx.de> writes:
> On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote:
> ...
> > Yes, there are a number of ways you can get to the situation where
> > you can not pop the stash.  How to resolve this is unclear from
> > the results of the failed pop.  I finally ended up resolving it by
> > committing the remaining changes, then popping the stash ( which
> > performed the merge successfully ), and finally doing a git reset
> > HEAD~1 to remove the temporary commit, but preserve the merged
> > results.  This seemed like a good deal of unnecessary trouble.
> 
> (Late to the game.) Actually, this is exactly what I would have proposed
> to do. Git is a bit shy on performing a merge into a locally modified
> file. I assumed so far that is because there is no way of aborting
> such a merge (resetting to the state of local modifications before the
> attempt). With the temporary commit you have a way of retrying the pop
> merge if you lost your way in it.

It would be nice if a.) git gave this advice when unable to "git stash pop"
(or "git stash apply") for newbie users, and b.) this solution was put
in documentation including git-stash(1) manpage.
 
> And I think that is a good idea; I never liked the way in which a cvs/svn
> update merged into locally modified files without a way to undo, and
> thus forcing you to clean up the potential mess manually. (Ok, they leave
> the old files lying arond, but that doesn't help rewinding the state.)

BTW. I sometimes wonder if Mercurial's transaction-based approach
isn't a superior solution...

> Andreas
> 
> -- 
> "Totally trivial. Famous last words."
> From: Linus Torvalds <torvalds@*.org>
> Date: Fri, 22 Jan 2010 07:29:21 -0800

-- 
Jakub Narebski

Re: stash refuses to pop

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/14/2012 12:27 AM, Andreas Krey wrote:
> (Late to the game.) Actually, this is exactly what I would have proposed
> to do. Git is a bit shy on performing a merge into a locally modified
> file. I assumed so far that is because there is no way of aborting
> such a merge (resetting to the state of local modifications before the
> attempt). With the temporary commit you have a way of retrying the pop
> merge if you lost your way in it.
> 
> And I think that is a good idea; I never liked the way in which a cvs/svn
> update merged into locally modified files without a way to undo, and
> thus forcing you to clean up the potential mess manually. (Ok, they leave
> the old files lying arond, but that doesn't help rewinding the state.)

That makes sense for the default behavior, but there should be a way to override.  Or maybe git could automatically stash the current state to a temporary commit before applying the requested stash and print the sha1 of that commit ( or save it as ORIG_HEAD ) so you could undo the stash pop/apply.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPi3YKAAoJEJrBOlT6nu75OXAH+gK4pfFomFgblw1sLb9Bpgud
0O88dtWWOr9/bNR6NIiIWj76x+xMiRMxuq2YP3/6vkuhGAtVxYqoHc/BkWUmzop/
oma30g244H17Oa0r9H0yf6n6v824xv3tVx166cQ0pVeBnnFs1GINxjODuD0QGTnH
VewepnyaYkPRSjgzrJShOadaxRZFZWUBNlncLbHMLBNJl+n4cMXsg9uasEv3rG73
Mw+zAKcMMf4zCfxE0T2dpbf0hOOde8PWtJY12RAYWvhn7YTVP9Uj+t3a9flb2UyB
zuo84Xv49meMB9ce4DDtANXeH8uKamBGk94NH6Khv6LewuG5SOS7DukDEJxA+B0=
=xaNu
-----END PGP SIGNATURE-----