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). -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
