On 06/24/2014 11:17 AM, Karanbir Singh wrote: > On 06/24/2014 05:15 PM, Johnny Hughes wrote: >> On 06/24/2014 10:58 AM, Karanbir Singh wrote: >>> On 06/24/2014 12:14 PM, Karanbir Singh wrote: >>>> hi, >>>> >>>> Working around stacked updates is an interesting issue. eg. Kernel >>>> needed patches into the GA release, for us to hit our GA tree, but it >>>> had also been updated for the zero-day update. >>> the latest kernel update from upstream dropped into git a short while >>> back, https://git.centos.org/log/rpms!kernel.git/refs!heads!c7 and it >>> seems to slot in quite nicely with the git path so far. >>> >>> So unless there are any objections in the near future, I would say we >>> have a process that allows us to arbitarily work on older content, in >>> side branches without stamping on c7/ >> Works fine for me, I can tell what is pushed content and what is >> modified content. The only suggestion I would have is for the last >> commit for a version, we get the NVR in the commit name. (ie, it would >> have been better if revision 315459 had 3.10.0-123.el7 in the commit >> message and if f355f5 had 3.10-0-123.1.2.el7 in the commit message. >> >> But other than that minor comment, the process seems great. >> >> And It is not hard to see the flow even without that, so it "works for me". >> > I was thinking about that - part of the challenge is then going to be > howdo we implement that with the git-am flow. If the patches are already > in and their commit messages are already set ... > > otherwise, totally agree - having dupe commit messages is a bit > annoying, and it needs a git branch patch visualisation to workout where > the stuff came from and what srpm it applied to. > > ofcourse, not a problem for people not needing to edit content > retrospectively ( hopefully that will be us, once C7 is out of the door). Right .. we could, I think, do a 'git commit --amend' after the "git am" to edit the commit comment, I think (before doing the next SRPM in the set) .. then do the second set after that amend edit. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140624/aaa0a70e/attachment-0007.sig>