This is the mail thread where Chris raised it: http://mail-archives.apache.org/mod_mbox//zookeeper-dev/201607.mbox/%3cd3b6a1e8.4977a%25cnaur...@hortonworks.com%3e <http://mail-archives.apache.org/mod_mbox//zookeeper-dev/201607.mbox/%3cd3b6a1e8.4977a%cnaur...@hortonworks.com%3E>
-Flavio > On 20 Sep 2016, at 13:13, Edward Ribeiro <edward.ribe...@gmail.com> wrote: > > Just out of curiosity, what's the motivation behind getting rid of > CHANGES.txt? > > Eddie > > On Mon, Sep 19, 2016 at 8:11 PM, Benjamin Reed <br...@apache.org> wrote: > >> what you are suggesting sounds good, but i don't know how to do it? since >> in the end we are still just accepting diffs on patches, the only thing >> that changes is that we use svn rather than git right? >> >> i LOVE chris's idea! lets do it! >> >> ben >> >> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <ph...@apache.org> wrote: >> >>> Ben, do you also want to update the "Applying a patch" section to make it >>> git specific? >>> >>> We (committers) should move to a model where authors get proper credit in >>> git. Our old workflow in svn resulted in only the committer being listed >>> (except that we listed the patch author in the commit message). We should >>> move to a model where the author of the patch gets proper credit in git. >> I >>> believe we will get that if we use git for patch creation/application? >>> >>> Chris brought up getting rid of CHANGES.txt recently on the dev list in a >>> separate thread - Chris do you want to implement that change now that >> we've >>> moved to git? >>> >>> Patrick >>> >>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <br...@apache.org> wrote: >>> >>>>> 1) actually in the previous step that was just adding new files. you >>>>> still >>>>>> need the commit -a for the rest of the changes. that's my normal >>>>> workflow. >>>>> >>>>> I think that will be confusing for most folks. They typically stage >>>>> all the changes and then commit or don't stage and use -a. >>>>> >>>> >>>> do you mind fixing it with your workflow. commit -a doesn't get new >>>> files, which is why you need to do the add, but i'm not the most >>>> sophisticated git user, so >>>> >>>> >>>>> >>>>>> 2) i figured since we are using git now that we should use git's >>>>> default. >>>>>> the patch should work (by default it seems to strip the first path >>>>> element). >>>>>> does it not work for you? >>>>>> >>>>> >>>>> It will fail precommit in it's current state. >>>>> >>>> >>>> fixed >>>> >>> >>> >>
