On 06/08/16 12:08, David Woodhouse wrote: > On Thu, 2016-05-19 at 10:30 +0200, Laszlo Ersek wrote: >> >> master final merge >> *-------*-----*-------*--------*-----------*------*----*------> >> \ \ \ / >> \ \ \ / >> *-*-*-[discont.] *-*-*-[discont.] *-*-*-* >> feature rebased feature rebased feature >> >> >> 1.2. Merging. It has the benfit that your development history on the >> feature (staging) branch will be preserved in edk2 master too. > > Do not underestimate this benefit. When you are rebasing a complex > piece of work, and changes in master have affected things which it > interacts with (like OpenSSL being changed and updated), there is a > *distinct* possibility that during one of the rebases, you introduce a > bug. Something that *did* work when you originally wrote your code, now > no longer works. > > And because you rebased and the old discontinued branches are lost in > the mists of time (and no longer reachable from the version control > history), the effect is basically that it *never* worked. You're making > it look like you committed code that was broken from day one. > > So six months down the line when you realise that some specific corner > case is broken, and you think "oh, I could have *sworn* I tested that", > and you go back with all the tools like git-bisect to find where the > breakage occurred, you're screwed because the history doesn't reflect > reality. > > If you rebase, you are not using the version control system as it is > intended to be used. You are wilfully *damaging* the history, and you > do so at your peril. > >> On the other hand, you have to be careful about the frequency of >> master-to-staging merges. If you do it very frequently, you'll end up >> with a complex history. > > Conversely... do not *overestimate* the relevance of a "complex > history". History is non-linear and contains merged. That is an > accurate representation of what happened, which is what a version > control system exists to report. > > You'll mostly neither notice nor care even if you do a gratuitous merge > from master into your topic branch every day. It just annoys the neat- > freaks, that's all. So sure, merge back from master only when you > *need* to. But don't lose sleep over it. > >> In the Linux community, merging is preferred, and a master-to-topic >> merge is advised whenever the master branch receives a feature or a >> bugfix that is important for the topic branch as well. That is, no >> spurious merges. > > That's the norm for basically everyone who is using the version control > system as it is intended. There are some exceptions, but they're mostly > doing odd things like pretending git is svn (as edk2 currently is, but > hopefully not for *too* much longer).
FWIW, I too feel that for such long-living feature branches like HTTPS-TLS, merging is preferable (both for periodic master-to-feature syncs, and for the final feature-to-master incorporation). The risk for rebases to regress the (presumably many and finicky) patches on the feature branch is just too high otherwise -- the longer the feature development, the higher the risk, IMO. Just my two cents anyway -- the decision is ultimately up to the HTTPS-TLS developers, it's their code and work. :) Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
