Hi Allen, To make it simpler for you to address my question, does "git log" miss commits or report redundant commits on a branch with merged ancestor branches?
Thanks. --Yongjun On Tue, Mar 17, 2015 at 11:21 AM, Allen Wittenauer <a...@altiscale.com> wrote: > > Nope. I’m not particularly in the mood to write a book about a > topic that I’ve beat to death in private conversations over the past 6 > months other than highlighting that any solution needs to be able to work > against scenarios like we had 3 years ago with four active release branches > + trunk. > > On Mar 17, 2015, at 10:56 AM, Yongjun Zhang <yzh...@cloudera.com> wrote: > > > Thanks Ravi and Colin for the feedback. > > > > Hi Allen, > > > > You pointed out that "git log" has problem when dealing with branch that > > has merges, would you please elaborate the problem? > > > > Thanks. > > > > --Yongjun > > > > On Mon, Mar 16, 2015 at 7:08 PM, Colin McCabe <cmcc...@alumni.cmu.edu> > > wrote: > > > >> Branch merges made it hard to access change history on subversion > >> sometimes. > >> > >> You can read the tale of woe here: > >> > >> > http://programmers.stackexchange.com/questions/206016/maintaining-svn-history-for-a-file-when-merge-is-done-from-the-dev-branch-to-tru > >> > >> Excerpt: > >> "....prior to Subversion 1.8. The files in the branch and the files in > >> trunk are copies and Subversion keeps track with svn log only for > >> specific files, not across branches." > >> > >> I think that's how the custom of CHANGES.txt started, and it was > >> cargo-culted forward into the git era despite not serving much purpose > >> any more these days (in my opinion.) > >> > >> best, > >> Colin > >> > >> On Mon, Mar 16, 2015 at 4:49 PM, Ravi Prakash <ravi...@ymail.com> > wrote: > >>> +1 for automating the information contained in CHANGES.txt. There are > >> some changes which go in without JIRAs sometimes (CVEs eg.) . I like git > >> log because its the absolute source of truth (cryptographically secure, > >> audited, distributed, yadadada). We could always use git hooks to force > a > >> commit message format. > >>> a) cherry-picks have the same message (by default) as the original)b) > >> I'm not sure why branch-mergers would be a problem?c) "Whoops I missed > >> something in the previous commit" wouldn't happen if our hooks were > >> smartishd) "no identification of what type of commit it was without > hooking > >> into JIRA anyway." This would be in the format of the commit message > >>> > >>> Either way I think would be an improvement. > >>> Thanks for your ideas folks > >>> > >>> > >>> > >>> On Monday, March 16, 2015 11:51 AM, Colin P. McCabe < > >> cmcc...@apache.org> wrote: > >>> > >>> > >>> +1 for generating CHANGES.txt from JIRA and/or git as part of making a > >>> release. Or just dropping it altogether. Keeping it under version > >>> control creates lot of false conflicts whenever submitting a patch and > >>> generally makes committing minor changes unpleasant. > >>> > >>> Colin > >>> > >>> On Sat, Mar 14, 2015 at 8:36 PM, Yongjun Zhang <yzh...@cloudera.com> > >> wrote: > >>>> Hi Allen, > >>>> > >>>> Thanks a lot for your input! > >>>> > >>>> Looks like problem a, c, d you listed is not too bad, assuming we can > >> solve > >>>> d by pulling this info from jira as Sean pointed out. > >>>> > >>>> Problem b (branch mergers) seems to be a real one, and your approach > of > >>>> using JIRA system to build changes.txt is a reasonably good way. This > >> does > >>>> count on that we update jira accurately. Since this update is a manual > >>>> process, it's possible to have inconsistency, but may be not too bad. > >> Since > >>>> any mistake found here can be remedied by fixing the jira side and > >>>> refreshing the result. > >>>> > >>>> I wonder if we as a community should switch to using your way, and > save > >>>> committer's effort of taking care of CHANGES.txt (quite some save > IMO). > >>>> Hope more people can share their thoughts. > >>>> > >>>> Thanks. > >>>> > >>>> --Yongjun > >>>> > >>>> On Fri, Mar 13, 2015 at 4:45 PM, Allen Wittenauer <a...@altiscale.com> > >> wrote: > >>>> > >>>>> > >>>>> I think the general consensus is don’t include the changes.txt file > in > >>>>> your commit. It won’t be correct for both branches if such a commit > is > >>>>> destined for both. (No, the two branches aren’t the same.) > >>>>> > >>>>> No, git log isn’t more accurate. The problems are: > >>>>> > >>>>> a) cherry picks > >>>>> b) branch mergers > >>>>> c) “whoops i missed something in that previous commit” > >>>>> d) no identification of what type of commit it was without hooking > into > >>>>> JIRA anyway. > >>>>> > >>>>> This is why I prefer building the change log from JIRA. We already > >> build > >>>>> release notes from JIRA, BTW. (Not that anyone appears to read them > >> given > >>>>> the low quality of our notes…) Anyway, here’s what I’ve been > >>>>> building/using as changes.txt and release notes: > >>>>> > >>>>> https://github.com/aw-altiscale/hadoop-release-metadata > >>>>> > >>>>> I try to update these every day. :) > >>>>> > >>>>> On Mar 13, 2015, at 4:07 PM, Yongjun Zhang <yzh...@cloudera.com> > >> wrote: > >>>>> > >>>>>> Thanks Esteban, I assume this report gets info purely from the jira > >>>>>> database, but not "git log" of a branch, right? > >>>>>> > >>>>>> I hope we get the info from "git log" of a release branch because > >> that'd > >>>>> be > >>>>>> more accurate. > >>>>>> > >>>>>> --Yongjun > >>>>>> > >>>>>> On Fri, Mar 13, 2015 at 3:11 PM, Esteban Gutierrez < > >> este...@cloudera.com > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> JIRA already provides a report: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327179&styleName=Html&projectId=12310240 > >>>>>>> > >>>>>>> > >>>>>>> cheers, > >>>>>>> esteban. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Cloudera, Inc. > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Mar 13, 2015 at 3:01 PM, Sean Busbey <bus...@cloudera.com> > >>>>> wrote: > >>>>>>> > >>>>>>>> So long as you include the issue number, you can automate pulling > >> the > >>>>>>> type > >>>>>>>> from jira directly instead of putting it in the message. > >>>>>>>> > >>>>>>>> On Fri, Mar 13, 2015 at 4:49 PM, Yongjun Zhang < > >> yzh...@cloudera.com> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I found that changing CHANGES.txt when committing a jira is error > >>>>> prone > >>>>>>>>> because of the different sections in the file, and sometimes we > >> forget > >>>>>>>>> about changing this file. > >>>>>>>>> > >>>>>>>>> After all, git log would indicate the history of a branch. I > >> wonder if > >>>>>>> we > >>>>>>>>> could switch to a new method: > >>>>>>>>> > >>>>>>>>> 1. When committing, ensure the message include the type of the > >> jira, > >>>>>>> "New > >>>>>>>>> Feature", "Bug Fixes", "Improvement" etc. > >>>>>>>>> > >>>>>>>>> 2. No longer need to make changes to CHANGES.txt for each commit > >>>>>>>>> > >>>>>>>>> 3. Before releasing a branch, create the CHANGES.txt by using > "git > >>>>> log" > >>>>>>>>> command for the given branch.. > >>>>>>>>> > >>>>>>>>> Thanks. > >>>>>>>>> > >>>>>>>>> --Yongjun > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Sean > >>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>> > >>> > >> > >
