That isn't the question. The presumption is that you do not have a set of patches to reorganize. You have a set of files that should be replaced by a different set of files and from that you want to organize the diff into a logical sequence of patches on the assumption that a single patch that effected the diff would be too big.
On Thu, Nov 20, 2014 at 3:43 AM, Taras Kondratiuk < [email protected]> wrote: > On 11/19/2014 04:15 PM, Bill Fischofer wrote: > > Slightly off-topic, but relevant to ODP development and something we > > just discussed in the arch hangout. But this captures the problem I was > > trying to articulate. I'd appreciate thoughts and recommendations for > > best practices as to how to deal with this. > > > > Say I have a repository with a master branch that consists of a set of > > files with their own commit histories. > > > > Now assume that I'm given another set of files that differ from some > > subset of the master files in varying ways. How these files came to be > > is not relevant to this question. > > > > If I do a diff between the master and the new files what I'd have is a > > single patch that transforms the master files into new versions that > > reflect the new files, however this patch may be too large to be > > conveniently reviewed/digested. > > > > So the question is this. How can I best reorganize this single large > > patch into a series of orthogonal patches that can be submitted against > > the master that combined produce the same results as the original giant > > patch? > > > > I believe this scenario captures the essence of the problem Ola and I > > were trying to articulate. > > > > Thanks for any insights and tool suggestions for this. > > This example missing important details like: > - Are these changes made on top of the same commit you want to apply > them to? > - Are these new changes committed as one big patch or they are still > in your working tree? > > Depending on these details first steps will be different, but anyway > you need to come to a state when you have all your changes unstashed in > a working directory. > Then with 'git add -p' pick changes related to a first patch. > Commit them. > Pick changes for a next patch and commit them. > Proceed like this until you commit everything. > > Important thing to mention: situation described here can be avoided by > sorting patches at least partially during development. That takes just > a bit more time, but a the end changes are split into major pieces, so > converting them to a clean patch series is much easier. >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
