I do have some experience maintaining my branches (in other projects) that eventually get submitted as pull requests to a master. And I always find it easier to keep my branch in sync by doing frequent merge form master. I agree that it probably makes more sense to do this a couple of times a week (or so) manually, and resolve any merge conflicts, than try to automate it.
At this point, I am working on enabling the HTTPS/TLS feature, but I need to do so in a code base that is up-to-date with EDK2 master. So the main issue I have is merging from (the now falling behind) HTTPS/TLS branch into my code base (which is tracking EDK2). As Laszlo said, it is already getting mad because of all of the HTTP fixes in EDK2. Thanks, --Samer -----Original Message----- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thursday, May 19, 2016 5:51 AM To: Gao, Liming <liming....@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>; El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Li, Ruth <ruth...@intel.com>; Ye, Ting <ting...@intel.com>; Long, Qin <qin.l...@intel.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Justen, Jordan L <jordan.l.jus...@intel.com>; Kinney, Michael D <michael.d.kin...@intel.com>; Leif Lindholm (Linaro address) <leif.lindh...@linaro.org> Subject: Re: [edk2] edk2-staging/HTTPS-TLS On 05/19/16 11:53, Gao, Liming wrote: > Ersek: > I remember we discuss Rebase or Merge before. The conclusion is to > keep the liner history in edk2 project. So, I think rebase is better. Okay. > If we choose option 1, I suggest to setup mirror task in server and > auto run regular sync. If the confliction happens, it sends the mail > to edk dev list and let owner follow up. Hmm... I'm not sure about an automated rebase. I always have a number of downstream branches (in my private repo) that I rebase almost every day to new master. However, occasionally I'm so deep in work that I don't want to rebase for a week, for example. An automated rebase would be very annoying in such situations, when I'm in the middle of shuffling around my patches. I think it's the owner's responsibility after all. If they are fine with an automated rebase, so be it; but the automatism should be possible to disable. Thanks Laszlo > Thanks > Liming >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >> Of Laszlo Ersek >> Sent: Thursday, May 19, 2016 4:31 PM >> To: Wu, Jiaxin <jiaxin...@intel.com>; El-Haj-Mahmoud, Samer >> <samer.el- haj-mahm...@hpe.com>; Li, Ruth <ruth...@intel.com>; Ye, >> Ting <ting...@intel.com>; Long, Qin <qin.l...@intel.com>; edk2- >> de...@lists.01.org <edk2-de...@ml01.01.org>; Justen, Jordan L >> <jordan.l.jus...@intel.com>; Kinney, Michael D >> <michael.d.kin...@intel.com>; Leif Lindholm (Linaro address) >> <leif.lindh...@linaro.org> >> Subject: Re: [edk2] edk2-staging/HTTPS-TLS >> >> On 05/19/16 05:35, Wu, Jiaxin wrote: >>> Hi all, >>> There are two ways to sync HTTPS-TLS branch with EDK2 master: >>> >>> 1. Sync all changes in EDK2 master to branch by rebasing the whole >>> feature branch. Need frequency request to sync edk2-staging/master >>> to latest edk2/master. This way can also keep branch code go >>> straight with edk2/master. >>> >>> 2. Only sync HTTPS/TLS related patches to branch (e.g. HttpDxe >>> update). That means to use one stable edk2 tag for >>> edk2-staging/HTTPS-TLS branch development. By this way, frequency >>> request to sync edk2-staging/master to latest edk2/master can be >>> avoided but maybe some bugs fixed in edk2/master can't be synced to >>> branch timely. >>> >>> Both of them are not easy since it's probable that each updates in >>> edk2 trunk may cause the conflicts with the HTTPS code (HttpDxe >>> driver and CryptyPkg especially). >>> >>> Effort is almost. Which one do you prefer? >> >> I'm chiming in here not because I have a direct interest in the >> HTTPS-TLS feature set, but because this feature branch seems to be >> the first real-life test case of edk2-staging. I'd like to add three points. >> >> (a) The ultimate goal of a staging branch is to be merged into edk2 >> master when the feature is complete. If you try to save the effort >> now that would be necessary for rebasing the feature branch, you will >> go >> *mad* when you finally want to merge the staging branch into edk2 >> master. The larger you allow the divergence to grow, the >> (non-linearly) harder time you will have when you try to do the final >> merge into edk2 master. So, the trick is to stay sensibly close as >> possible to edk2 master on the staging branch. >> >> For this reason, option (1) is very strongly preferable. Option (2) >> -- which is called "cherry picking" or "backporting" -- is really >> only an option for branches that are never meant to be merged back >> into the master branch. Given that HTTPS-TLS is not such a downstream >> branch (instead, it is a development, topic branch), option (2) doesn't >> apply. >> >> (b) For option (1), there are actually two methods, rebasing and merging: >> >> 1.1. Rebasing. It has the drawback that it throws away your prior >> development history on the feature (staging) branch. Many people >> don't like this. On the other hand, you can do it as frequently as >> you like, without creating a mess of commit history. >> >> Here's a diagram: >> >> 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. 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. >> >> 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. >> >> Here's a diagram: >> >> master final merge >> back into >> master *-------*-----*-------*--------*-----------*------*----*------> >> \ \ \ / >> \ \ \ / >> *-*-*-----------------*---*--------*------ *-*-*-* >> feature ^ merge from master ^ another merge >> triggered by from master >> important new stuff >> in master >> >> I think that for edk2 staging branches, both 1.1. (= rebasing staging >> to >> master) and 1.2. (= merging master into staging) are appropriate. >> Both can facilitate the final merge back into master. >> >> Option (2) (= cherry-picking patches from master to staging) is *not* >> appropriate. >> >> Thanks >> Laszlo >> >> >>> >>> Thanks. >>> Jiaxin >>> >>>> -----Original Message----- >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >>>> Of >> El- >>>> Haj-Mahmoud, Samer >>>> Sent: Thursday, May 19, 2016 6:10 AM >>>> To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org >>>> Subject: [edk2] edk2-staging/HTTPS-TLS >>>> >>>> Jiaxin, >>>> >>>> The HTTPs-TLS branch is behind EDK2 master, and they are quite a >>>> few conflicts to try to keep up with both. Can you please sync the >>>> branch from >>>> EDK2 master? >>>> >>>> Thanks, >>>> --Samer >>>> >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
