Jordan, For single patch sync, I agree with using "patch+message" in the first line is better for git to summarize the log history. But it is rare case.
On most cases, to reduce the maintain effort (hundreds of patches for each branch release. Also sometimes, some patch maybe hard to be applied or to be synced to branch) and to reduce the revision number increasing, we shall check-in a serial of patches together. One example in MdeModulePkg as blow: Sync patches r14006, r14034 and r14035 from main trunk. 1. Base on the value type to get the value for default opcode. 2. Base on the type field to generate numeric opcode. 3. Base on the type field to generate oneof opcode. We already provided enough original patches information. If the git developer wants for details of some patch, he/she could use get the whole log body instead of from the summary log. Do you any better suggestion on it? Why we delete the BaseTools and copy the updated BaseTools from main trunk is to try best to keep original log information from main trunk. You could see the log of BaseTools on branches for it. Thanks! Jeff -----Original Message----- From: Jordan Justen [mailto:jljus...@gmail.com] Sent: Tuesday, September 30, 2014 6:50 AM To: edk2-devel@lists.sourceforge.net; Fan, Jeff Subject: UDK2014.SP1 maintenance - Re: edk2[16182] Sync patch r16181 from main trunk. Just wanted to note that git cherry-pick would make this type of maintenance easier, and would produce a more useful result is the branch history. (You'd see the original patch+message rather than 'sync patch r#...') r16182 | Sync patch r16181 from main trunk. r16180 | Sync patch r16179 from main trunk. === I don't think it is a good idea to update the branch packages by deleting and copying newer versions. This means if anyone checks out r16176, they will have an unusable tree. Normally you'd want to avoid that so a tree could be bisected to locate the source of some breakage. Once again, I think this is something where git cherry-pick could produce a more useful result by having each patch appear individually on the branch's history. But, lacking git, perhaps creating a patch with svn and applying it to the branch would allow you to sync in the new changes from the main branch. (Without having to delete and copy.) r16177 | Copy BaseTools r16160 to UDK2014.SP1 Branch. r16176 | Delete BaseTools from UDK2014.SP1 Branch. -Jordan === r16175 | Copy ShellBinPkg r16166 to UDK2014.SP1 Branch. r16174 | Copy ShellPkg r16163 to UDK2014.SP1 Branch. r16173 | Delete ShellPkg and ShellBinPkg from UDK2014.SP1 Branch. r16164 | Sync patch r16128 from main trunk. r16151 | Correct the convert hex string to decimal value logic. r16130 | Sync patch r16129 from main trunk. r16119 | Create UDK2014.SP1 BaseTools branch based on revision 16114 r16118 | Create UDK2014.SP1 BaseTools branch based on revision 16114 r16117 | Remove UDK2014.SP1 BaseTools branch. r16111 | Create UDK2014.SP1 branch On Sat, Sep 27, 2014 at 6:15 PM, <vanj...@users.sourceforge.net> wrote: > Revision: 16182 > http://sourceforge.net/p/edk2/code/16182 > Author: vanjeff > Date: 2014-09-28 01:15:46 +0000 (Sun, 28 Sep 2014) > Log Message: > ----------- > Sync patch r16181 from main trunk. > Fix an issue on FixedMtreProgramming - AND/OR mask incorrect. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jeff Fan <jeff....@intel.com> > > Revision Links: > -------------- > http://sourceforge.net/p/edk2/code/16181 > > Modified Paths: > -------------- > branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c > > Modified: > branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c > =================================================================== > --- branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c > 2014-09-28 01:07:13 UTC (rev 16181) > +++ branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c > 2014-09-28 01:15:46 UTC (rev 16182) > @@ -381,7 +381,7 @@ > *Len -= mFixedMtrrTable[MsrNum].Length; > *Base += mFixedMtrrTable[MsrNum].Length; > } > - TempQword = AsmReadMsr64 (mFixedMtrrTable[MsrNum].Msr) & > (~ClearMask | OrMask); > + TempQword = (AsmReadMsr64 (mFixedMtrrTable[MsrNum].Msr) & > + (~ClearMask)) | OrMask; > AsmWriteMsr64 (mFixedMtrrTable[MsrNum].Msr, TempQword); > > return EFI_SUCCESS; > > > ---------------------------------------------------------------------- > -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog > Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI > DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download > White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with > EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg. > clktrk _______________________________________________ > edk2-commits mailing list > edk2-comm...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-commits ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
