On Wed, Apr 11, 2012 at 4:47 AM, Andrew Ardill <andrew.ardill@xxxxxxxxx> wrote: > > On 11 April 2012 04:56, Phillip Susi <psusi@xxxxxxxxxx> 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 -- 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