On 11 April 2012 04:56, Phillip Susi <psusi@xxxxxxxxxx> wrote: > On 4/10/2012 2:05 PM, Junio C Hamano wrote: >> >> Phillip Susi<psusi@xxxxxxxxxx> 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 -- 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