Thanks, Eric. The new git stash branch command you mentioned will come in handy. >From a user's perspective, it doesn't make sense to stage unconflicted changes after stash apply. When I stash changes, these changes are usually not ready for committing. I suppose git uses the index to differentiate between conflicted and unconflicted changes. So, its not a big deal. Just a bit surprising. Thanks again for your help! On Mon, Oct 18, 2010 at 1:18 PM, Eric Raible <raible@xxxxxxxxxxx> wrote: > On 11:59 AM, Pretty Boy Floyd wrote: >> Hello! >> >> I am running msysgit 1.7.3.1. If I run stash apply, and there is a conflict, >> all of my stash changes get staged. Is this the correct behaviour? I found it a >> little surprising. > > My tests indicate that the same thing happens as with any conflicted merge. > Namely: non-conflicting changes get staged, and conflicting changes are left > only in the working directory (with conflict markers added as appropriate). > > See http://progit.org/book/ch3-2.html#basic_merging, > especially the part on conflicts. > >> Another question: if I have stashed 10 files, and there is a conflict in one of >> them, will stash apply abort when it has a conflict, or will it apply all >> non-conflicted files. > > Same as above. In both cases the stash is unaffected, which allows > you to reset and try again. > >> Finally, if I do the following: >> >> git stash >> git pull >> git stash apply >> >> and another developer has removed a file that I have stashed, then I am unable >> to apply the stash on this file. How can I retrieve my changes from the stash? > > One nice (relatively new feature) is "git stash branch", which makes a new > branch from an existing stash. > > HTH - Eric > -- 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