On Sat, 2013-02-02 at 01:23 +0100, Laszlo Ersek wrote: > 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.)
Indeed. And often it doesn't *matter*. But for longer sets of commits where it *might* matter, such as the set of 13 patches I've posted to the SeaBIOS mailing list, the maintainer has the *option* of pulling from my git tree instead. Which I half expect Kevin to do. > With merges you cannot export the entire history as a linear series of > patches, which could be useful sometimes (think RPM etc). For things like RPM there are two common ways to do it. Either you just cherry-pick the individual patches you want, or you do a wholesale 'update from last release to latest git HEAD' which can be a single patch anyway. > Also I think the pull request based workflow tends to shift the conflict > resolution on the maintainer, doesn't it? This is equally true of sending patches to the list. If I check out the SVN tree and spend a week working on something, then send a patch, the maintainer who receives the patch then has to apply it to the latest tree rather than the week-old tree. But with a DVCS it's kind of expected that before submitting a pull request, the sender will do a merge with the latest upstream tree and check that things appear to work OK. They can even do the merge and *keep* the result, so that the maintainer who pulls it doesn't need to think at all. But either way it's still a choice for the maintainer; they don't *have* to pull git trees and can just continue to apply patches. Git makes it easier for you either way. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ 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
