You are right about conflicting changes. They are hard to manage as order independent changes with any tool. In stgit context I often split big change into multiple ordered patches and yes I know what piece (incremental edit) should be added to what patch. Classic example: doing refactoring around main task. Refactoring goes into one patch, main changes into another. It allows greatly simplify review process.
But common case for me is to have multiple independent patches for different features/bug fixes. For example one current project has 12 patches, another one has 5 patches. Two or three are dedicated to current work. Rest are drafts with ideas.
I'm kind of confused on the commit --all part.
Me too. Almost always task is represented by a single patch. And I push changes on patch basis. One patch -> one review.
Comments
You are right about conflicting changes. They are hard to manage as order independent changes with any tool. In stgit context I often split big change into multiple ordered patches and yes I know what piece (incremental edit) should be added to what patch. Classic example: doing refactoring around main task. Refactoring goes into one patch, main changes into another. It allows greatly simplify review process.
But common case for me is to have multiple independent patches for different features/bug fixes. For example one current project has 12 patches, another one has 5 patches. Two or three are dedicated to current work. Rest are drafts with ideas.
Me too. Almost always task is represented by a single patch. And I push changes on patch basis. One patch -> one review.