I'm afraid that link doesn't work for me, updated link: http://markmail.org/message/4engzfzfpjd42smp
Patrick On Tue, Sep 20, 2016 at 5:51 AM, Flavio Junqueira <f...@apache.org> wrote: > 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 > > -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 > > > > > >