On 02/02/13 00:17, David Woodhouse wrote: > My own commits no longer exist in the form > that I made and tested them; they get committed on top of whatever > *other* work happened in the SVN tree before I finally got them merged.
I don't think you can avoid that with series sent to the list for review, and for the maintainer to apply from there. (Unless you insist in the blurb that the maintainer apply them on top of a specific commit, in a separate branch, and then merge it as well.) > So tools like 'git bisect' no longer work. They might indicate that a > problem was introduced by one of my changes when in *fact* it didn't > occur then at all in the original; it was a combination of my changes > *and* the other changes that ended up in the repository before my patch > was merged. > > With git preserving *full* history, the blame gets clearly laid at the > *merge* where it should be, and the merge is visible as a separate step > in the revision history. With merges you cannot export the entire history as a linear series of patches, which could be useful sometimes (think RPM etc). Also I think the pull request based workflow tends to shift the conflict resolution on the maintainer, doesn't it? Laszlo ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
