Piotr Krukowiecki <piotr.krukowiecki@xxxxxxxxx> writes: > How about following workflow? > > # ... hack hack hack ... > $ git add --patch foo > $ git stash save --keep-index > $ build/test first part # note I have removed the "edit" part > > There are two possibilities now: > > 1. You're happy with the result - you commit your changes: > > $ git commit -m 'First part' > $ git stash pop > > Important: there will be no conflicts in this case, and committed > changes won't be reverted/applied/conflicted, because you have > not edited them! Exactly; I won't take _any_ credit for --keep-index (I wasn't involved deeply in "git stash"), but the above matches my understanding of its primary intended use case. For this to work well, the stash should record the index that is going to be committed and the work tree you had before stashing. > 2. You're not happy with the result - maybe something does not > build and you need to stage more changes, or maybe fix is not > working yet. > > You should first pop your stashed changes! This way you'll avoid > conflicts, you'll be able to stage/modify other changes. So the > next steps are like this: > > $ git stash pop > $ edit/add -p > $ git stash save --keep-index > > and now you're back to the "build/test" part. Yes. -- 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