Interesting, thanks for the update Edward. "close via a dummy commit" - I don't think that's possible, doesn't GH match up a PR to a commit based on the hash?
Patrick On Tue, Dec 6, 2016 at 6:17 AM, Edward Ribeiro <edward.ribe...@gmail.com> wrote: > Oh, Patrick (and Flavio, and Ben Reed), > > I asked some questions to one ASF committer that has been using the > Github-JIRA-Apache combo for a while now. According to him, committers > *cannot* manually close 3rd party PRs. :( He said this is a combination of > Github limitations and INFRA policies, his explanations below: > > Question: 1) Do committers have to contact ASF INFRA to be able to close > PR on Github mirror? Some people created bogus PR that we would like to > close, but they don't have this option now. Can INFRA give committers the > auth to close those 3rd party PRs? > > Answer: "You either have to ask INFRA, ask the author or close via a dummy > commit. In our project, we first ask the author and occasionally we ask > INFRA to close a bunch of them or a particularly bad one (someone had > created a PR for merging trunk to a stable branch, for example. That would > cause a PR build every time something was merged to trunk). > > Basically, if you have write access to the PRs, you also have write access > to the GitHub repository. And INFRA believes it's essential for the GitHub > repo to be read only. The writes flow from the Apache git repo. The Apache > git repo has more safeguards (although protected branches in GitHub could > help here, not sure if the Apache INFRA team has considered them)." > > Question: At Kafka, all the PR goes through GH? Or do you committers > usually apply patches directly to Apache git repo? > > Answer: "We now always use GitHub, we don't use patches any more" > Edward > > On Mon, Dec 5, 2016 at 9:07 PM, Patrick Hunt <ph...@apache.org> wrote: > > > No problem Edward. Did you get any insight on what to do with the PR? > > > > Patrick > > > > On Thu, Nov 24, 2016 at 10:52 AM, Edward Ribeiro < > edward.ribe...@gmail.com > > > > > wrote: > > > > > Hi, Patrick, > > > > > > Thanks for merging this change. :) > > > > > > Sincerely, I don't know why it didn't close the PR automatically. Nor > why > > > you can close it in the GH mirror. In any case, I manually closed it. > > > > > > I will ping folks from other Apache projects using similar tool to > > inquire > > > why it didn't close the PR and why it gave this 'write access' error > > > message. > > > > > > Edward > > > > > > > > > > > > On Fri, Nov 18, 2016 at 8:13 PM, Patrick Hunt <ph...@apache.org> > wrote: > > > > > >> Thanks Edward, this should be very helpful for folks. I committed, > > >> however I notice the PR is still open. I followed the steps here: > > >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ > > Committing+changes > > >> however I don't see a way to close the PR? https://github.com/apache/ > > >> zookeeper/pull/103 says I don't have "write access". > > >> > > >> Patrick > > >> > > >> On Thu, Nov 10, 2016 at 10:23 AM, Edward Ribeiro < > > >> edward.ribe...@gmail.com> wrote: > > >> > > >>> Hi Patrick, > > >>> > > >>> I've just opened a PR https://github.com/apache/zookeeper/pull/103/ > > PR > > >>> > > >>> It asks for JIRA_PASSWORD at CLI prompt *IF* it's absent but > > >>> JIRA_USERNAME > > >>> is already set. Please, when you have time, see if it fits what you > > need > > >>> and then I can open a JIRA, rename the feature branch, etc. > > >>> > > >>> Let me know if you have other ideas. I am open to other ways of > > >>> incorporating the passing of JIRA_PASSWORD too. > > >>> > > >>> Edward > > >>> > > >>> On Wed, Nov 9, 2016 at 5:03 PM, Edward Ribeiro < > > edward.ribe...@gmail.com > > >>> > > > >>> wrote: > > >>> > > >>> > Hi Patrick, > > >>> > > > >>> > We can change the script so that it asks for jira password input on > > CLI > > >>> > prompt if the JIRA username is set, for example. The change should > be > > >>> > straigthforward. > > >>> > > > >>> > Alternatively, the python systems I have dealt with put credentials > > for > > >>> > database access, etc, in configuration -- sometimes hidden -- files > > >>> (say, > > >>> > .env), but yet it is clear text stored. > > >>> > > > >>> > Anyone has other suggestions? > > >>> > > > >>> > Eddie > > >>> > > > >>> > Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <ph...@apache.org> > > >>> escreveu: > > >>> > > > >>> >> Is there any alternative to step 4 as documented here? > > >>> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Mergin > > >>> >> g+Github+Pull+Requests > > >>> >> > > >>> >> specifically it's asking to "export JIRA_PASSWORD=mypassword" > which > > I > > >>> feel > > >>> >> very uncomfortable doing. > > >>> >> > > >>> >> Patrick > > >>> >> > > >>> >> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro < > > >>> >> edward.ribe...@gmail.com> > > >>> >> wrote: > > >>> >> > > >>> >> > AFAIK, yes. I say, if you mean to run unit tests and other CI > > tasks > > >>> on > > >>> >> PR. > > >>> >> > > > >>> >> > PS: I have just created a simple script HowTo at > > >>> >> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/ > > >>> >> > Merging+Github+Pull+Requests > > >>> >> > and linked from https://cwiki.apache.org/confl > > >>> uence/display/ZOOKEEPER/ > > >>> >> > Index > > >>> >> > > > >>> >> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira < > f...@apache.org > > > > > >>> >> wrote: > > >>> >> > > > >>> >> > > What about QA, are we still missing a github pre-commit queue? > > >>> >> > > > > >>> >> > > -Flavio > > >>> >> > > > > >>> >> > > > On 26 Oct 2016, at 18:53, Michael Han <h...@cloudera.com> > > >>> wrote: > > >>> >> > > > > > >>> >> > > > The comment bridging should be fixed now - see INFRA-12752 > for > > >>> more > > >>> >> > > > details. > > >>> >> > > > > > >>> >> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han < > > >>> h...@cloudera.com> > > >>> >> > wrote: > > >>> >> > > > > > >>> >> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't > show > > >>> up on > > >>> >> > > JIRA. > > >>> >> > > >> > > >>> >> > > >> The bridge was working the day Infra made the change - see > > the > > >>> >> > previous > > >>> >> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems > stop > > >>> >> working. > > >>> >> > I > > >>> >> > > am > > >>> >> > > >> reopening INFRA-12752 and building a case. > > >>> >> > > >> > > >>> >> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro < > > >>> >> > > edward.ribe...@gmail.com> > > >>> >> > > >> wrote: > > >>> >> > > >> > > >>> >> > > >>> Dear community, > > >>> >> > > >>> > > >>> >> > > >>> The zk-merger-pr.py script has been merged into master > > >>> (thanks a > > >>> >> LOT > > >>> >> > > Ben > > >>> >> > > >>> Reed for reviewing/discussing/testing and commiting): > > >>> >> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597 > > >>> >> > > >>> > > >>> >> > > >>> As stated in the issue and on GH, this tool is a modified > > >>> version > > >>> >> of > > >>> >> > > >>> similar tools from Kafka, that is a copy of a Spark's one. > > It > > >>> has > > >>> >> > some > > >>> >> > > >>> rough edges so we will certainly benefit from further > > >>> enhancements > > >>> >> > and > > >>> >> > > >>> fixes. I changed the smallest possible pieces of code, > just > > to > > >>> >> make > > >>> >> > it > > >>> >> > > >>> work > > >>> >> > > >>> on a ZK repo so the credits go to the original authors. > > >>> >> > > >>> > > >>> >> > > >>> Some notes: > > >>> >> > > >>> > > >>> >> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't > > >>> show up > > >>> >> on > > >>> >> > > JIRA. > > >>> >> > > >>> Only the opening and closing of the issue. Can we double > > check > > >>> >> this > > >>> >> > as > > >>> >> > > >>> INFRA-12752 is closed, Michael Han? > > >>> >> > > >>> > > >>> >> > > >>> 2. I scribbled a draft on how use the tool at > > >>> >> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_ > > h7F1bUrq > > >>> >> > > >>> Xg3urw4Hm7KirQDpPIU/edit > > >>> >> > > >>> (still very crude, but feel free to improve it). I would > > like > > >>> to > > >>> >> move > > >>> >> > > >>> this > > >>> >> > > >>> text to https://cwiki.apache.org/confl > > >>> >> uence/display/ZOOKEEPER/Index > > >>> >> > > but > > >>> >> > > >>> looks like I don't have permission to create a page there > > >>> yet. Any > > >>> >> > > help? > > >>> >> > > >>> > > >>> >> > > >>> Best regards, > > >>> >> > > >>> Eddie > > >>> >> > > >>> > > >>> >> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han < > > >>> h...@cloudera.com> > > >>> >> > > wrote: > > >>> >> > > >>> > > >>> >> > > >>>> FYI infra did some work in INFRA-12752 and the git PR > > >>> comments > > >>> >> can > > >>> >> > be > > >>> >> > > >>>> pushed to Apache JIRA. > > >>> >> > > >>>> > > >>> >> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira < > > >>> f...@apache.org > > >>> >> > > > >>> >> > > >>> wrote: > > >>> >> > > >>>> > > >>> >> > > >>>>> This is not supported at the moment if nothing has > > changed: > > >>> >> > > >>>>> > > >>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 < > > >>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000> > > >>> >> > > >>>>> > > >>> >> > > >>>>> -Flavio > > >>> >> > > >>>>> > > >>> >> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed < > > br...@apache.org> > > >>> >> wrote: > > >>> >> > > >>>>>> > > >>> >> > > >>>>>> it doesn't look like we need to setup keys. this seems > to > > >>> work > > >>> >> for > > >>> >> > > >>> me: > > >>> >> > > >>>>>> > > >>> >> > > >>>>>> https://git-wip-us.apache.org/ > > #committers-getting-started > > >>> >> > > >>>>>> > > >>> >> > > >>>>>> it does seem strange that we aren't using public keys > and > > >>> that > > >>> >> i'm > > >>> >> > > >>>>> sticking > > >>> >> > > >>>>>> a password in .netrc :P i'm wondering if other projects > > >>> were > > >>> >> able > > >>> >> > to > > >>> >> > > >>>> get > > >>> >> > > >>>>>> this going over ssh. > > >>> >> > > >>>>>> > > >>> >> > > >>>>>> i'll take a whack at cleaning up the svn and subversion > > >>> >> > references. > > >>> >> > > >>>>>> > > >>> >> > > >>>>>> ben > > >>> >> > > >>>>>> > > >>> >> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier < > > >>> >> > > >>> cami...@apache.org> > > >>> >> > > >>>>>> wrote: > > >>> >> > > >>>>>> > > >>> >> > > >>>>>>> Hey folks, > > >>> >> > > >>>>>>> > > >>> >> > > >>>>>>> So I'm trying to get in a patch but this has not been > > >>> updated > > >>> >> to > > >>> >> > > >>> tell > > >>> >> > > >>>>>>> committers how to actually get the git keys set up: > > >>> >> > > >>>>>>> https://cwiki.apache.org/ > confluence/display/ZOOKEEPER/ > > >>> >> > > >>>>> Committing+changes > > >>> >> > > >>>>>>> > > >>> >> > > >>>>>>> Can someone float me a link that says how to do this? > > >>> >> > > >>>>>>> > > >>> >> > > >>>>>>> Also a bunch of our documentation still discusses SVN > > and > > >>> not > > >>> >> > git, > > >>> >> > > >>>> which > > >>> >> > > >>>>>>> means we are not done with this migration. If you were > > >>> pushing > > >>> >> > for > > >>> >> > > >>>> this > > >>> >> > > >>>>>>> change can you please do some due diligence on the > wikis > > >>> and > > >>> >> > > >>> correct > > >>> >> > > >>>> the > > >>> >> > > >>>>>>> stuff that refers to SVN? > > >>> >> > > >>>>>>> > > >>> >> > > >>>>>>> Thanks, > > >>> >> > > >>>>>>> C > > >>> >> > > >>>>>>> > > >>> >> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro < > > >>> >> > > >>>>> edward.ribe...@gmail.com> > > >>> >> > > >>>>>>> wrote: > > >>> >> > > >>>>>>> > > >>> >> > > >>>>>>>> Excuse me guys! > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed > > it > > >>> up. > > >>> >> I > > >>> >> > was > > >>> >> > > >>>> only > > >>> >> > > >>>>>>>> able to see the strange characters when I pasted on a > > >>> gist > > >>> >> text > > >>> >> > > >>> area. > > >>> >> > > >>>>> The > > >>> >> > > >>>>>>>> previous message is below, but if anyone is still > > having > > >>> >> trouble > > >>> >> > > >>> (I > > >>> >> > > >>>>> tried > > >>> >> > > >>>>>>>> to remove the weird character), I left a copy at: > > >>> >> > > >>>>>>>> https://gist.github.com/eribei > > >>> ro/da2a6a6c9a508610d52d0755fae > > >>> >> 835 > > >>> >> > 2d > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> "Hi, > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a > > straightforward > > >>> >> > > >>> adaptation > > >>> >> > > >>>> of > > >>> >> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into > > >>> Apache > > >>> >> git > > >>> >> > > >>> repo > > >>> >> > > >>>>> and > > >>> >> > > >>>>>>> a > > >>> >> > > >>>>>>>> subsequent closing of the PR on the GH side, among > > other > > >>> >> things > > >>> >> > > >>>>>>> (rewriting > > >>> >> > > >>>>>>>> of commit messages, etc). The current status is: the > > >>> script > > >>> >> > needs > > >>> >> > > >>> to > > >>> >> > > >>>> be > > >>> >> > > >>>>>>>> reviewed/validated by a committer. It has been some > > time > > >>> >> since I > > >>> >> > > >>>>> uploaded > > >>> >> > > >>>>>>>> the patch, so I gonna do another pass through it in > the > > >>> >> > meantime. > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> There are some workflow issues beyond the scope of > > >>> >> > ZOOKEEPER-2597 > > >>> >> > > >>>> that > > >>> >> > > >>>>>>> need > > >>> >> > > >>>>>>>> to be sorted out (IMO): > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket > before > > >>> doing > > >>> >> any > > >>> >> > > >>> GH > > >>> >> > > >>>> PR, > > >>> >> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title > > of > > >>> the > > >>> >> > form > > >>> >> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache > > >>> >> > JIRA-Github > > >>> >> > > >>>>>>>> integration and it's opening show up in the JIRA > > ticket. > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding > JIRA > > >>> >> ticket. > > >>> >> > > >>> There > > >>> >> > > >>>>> are > > >>> >> > > >>>>>>> a > > >>> >> > > >>>>>>>> class of PRs with "MINOR" title that represent > trivial > > >>> code > > >>> >> > > >>> changes > > >>> >> > > >>>> and > > >>> >> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. > Both > > >>> bypass > > >>> >> > the > > >>> >> > > >>>> JIRA > > >>> >> > > >>>>>>>> creation step, even tough they are still subject to > > >>> review. > > >>> >> It's > > >>> >> > > >>>> worth > > >>> >> > > >>>>>>>> adopting a similar approach for ZK project? > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra > > >>> project > > >>> >> > > >>>>> encourages, > > >>> >> > > >>>>>>>> but not demands, that contributors also upload a > patch > > >>> file > > >>> >> to > > >>> >> > > >>> JIRA > > >>> >> > > >>>>> even > > >>> >> > > >>>>>>> in > > >>> >> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I > > guess). > > >>> >> Or, at > > >>> >> > > >>>>> least, > > >>> >> > > >>>>>>> C* > > >>> >> > > >>>>>>>> project leaves up to the contributors to either open > a > > >>> GH PR > > >>> >> or > > >>> >> > > >>>> upload > > >>> >> > > >>>>>>> the > > >>> >> > > >>>>>>>> patch file to JIRA. > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> +1 about having a 'paper trail' of review comments on > > >>> JIRA > > >>> >> > and/or > > >>> >> > > >>>>> mailing > > >>> >> > > >>>>>>>> list (I would prefer the mailing list tbh). But as > > >>> Michael > > >>> >> and > > >>> >> > > >>> Flavio > > >>> >> > > >>>>>>>> pointed out, I never seen GH PR review **comments** > > being > > >>> >> > written > > >>> >> > > >>>> back > > >>> >> > > >>>>> to > > >>> >> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr > > projects, > > >>> >> that I > > >>> >> > > >>> have > > >>> >> > > >>>>>>>> followed more closely. > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> Eddie" > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han < > > >>> >> h...@cloudera.com> > > >>> >> > > >>>> wrote: > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is > > >>> unicode > > >>> >> > > >>>> character > > >>> >> > > >>>>>>>>> zero-width space, which might cause parsing trouble > > for > > >>> some > > >>> >> > mail > > >>> >> > > >>>>>>>> clients. > > >>> >> > > >>>>>>>>> > > >>> >> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira < > > >>> >> > f...@apache.org > > >>> >> > > >>>> > > >>> >> > > >>>>>>> wrote: > > >>> >> > > >>>>>>>>> > > >>> >> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did > you > > >>> write > > >>> >> > that > > >>> >> > > >>>> on a > > >>> >> > > >>>>>>>>>> phone or something? > > >>> >> > > >>>>>>>>>> > > >>> >> > > >>>>>>>>>> -Flavio > > >>> >> > > >>>>>>>>>> > > >>> >> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro < > > >>> >> > > >>>> edward.ribe...@gmail.com > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>>>> wrote: > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> Hi, > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a > > >>> >> > > >>>>>>>>>>> straightforward adaptation of > > >>> >> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR > into > > >>> >> Apache > > >>> >> > git > > >>> >> > > >>>>>>> repo > > >>> >> > > >>>>>>>>> and > > >>> >> > > >>>>>>>>>>> a > > >>> >> > > >>>>>>>>>>> subsequent closing of the PR on the GH side > > >>> >> > > >>>>>>>>>>> among other things (rewriting of commit > messages, > > >>> etc) > > >>> >> > > >>>>>>>>>>> . The current status is: the script needs to be > > >>> >> > > >>> reviewed/validated > > >>> >> > > >>>>>>>> by a > > >>> >> > > >>>>>>>>>>> committer. > > >>> >> > > >>>>>>>>>>> It has been some time since I uploaded the patch, > > so > > >>> I > > >>> >> gonna > > >>> >> > > >>> do > > >>> >> > > >>>>>>>>> another > > >>> >> > > >>>>>>>>>>> pass through it in the meantime. > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> T > > >>> >> > > >>>>>>>>>>> here are some workflow issues beyond the scope of > > >>> >> > > >>> ZOOKEEPER-2597 > > >>> >> > > >>>>>>>>>>> that need to be sorted out (IMO) > > >>> >> > > >>>>>>>>>>> : > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket > > before > > >>> >> doing > > >>> >> > > >>> any > > >>> >> > > >>>> GH > > >>> >> > > >>>>>>>> PR > > >>> >> > > >>>>>>>>>>> , that is, no JIRA-less PRs. > > >>> >> > > >>>>>>>>>>> The PR should have a title of the form > > >>> "ZOOKEEPER-xxxx: > > >>> >> > Title". > > >>> >> > > >>>>>>> This > > >>> >> > > >>>>>>>>> will > > >>> >> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and > it's > > >>> >> opening > > >>> >> > > >>> show > > >>> >> > > >>>> up > > >>> >> > > >>>>>>>> in > > >>> >> > > >>>>>>>>>> the > > >>> >> > > >>>>>>>>>>> JIRA ticket. > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> 2. > > >>> >> > > >>>>>>>>>>> OTOH, n > > >>> >> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA > ticket > > >>> >> > > >>>>>>>>>>> . > > >>> >> > > >>>>>>>>>>> There are a class of PR > > >>> >> > > >>>>>>>>>>> s > > >>> >> > > >>>>>>>>>>> with "MINOR" > > >>> >> > > >>>>>>>>>>> title > > >>> >> > > >>>>>>>>>>> that represent trivial code changes > > >>> >> > > >>>>>>>>>>> and "HOT-FIX" title that fix urgent, but simple > > >>> bugs. > > >>> >> Both > > >>> >> > > >>>>>>>>>>> bypass the JIRA creation step > > >>> >> > > >>>>>>>>>>> , even tough they are still > > >>> >> > > >>>>>>>>>>> subject to review > > >>> >> > > >>>>>>>>>>> . > > >>> >> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK > > project? > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> 3. IIRC > > >>> >> > > >>>>>>>>>>> (didn't find any page to confirm) > > >>> >> > > >>>>>>>>>>> , Cassandra project encourages, but not demands, > > that > > >>> >> > > >>> contributors > > >>> >> > > >>>>>>>> also > > >>> >> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a > GH > > >>> PR > > >>> >> > > >>>>>>>>>>> (as to leave a audit trail, I guess) > > >>> >> > > >>>>>>>>>>> . > > >>> >> > > >>>>>>>>>>> Or > > >>> >> > > >>>>>>>>>>> , > > >>> >> > > >>>>>>>>>>> at > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> least > > >>> >> > > >>>>>>>>>>> , > > >>> >> > > >>>>>>>>>>> C* project > > >>> >> > > >>>>>>>>>>> leave > > >>> >> > > >>>>>>>>>>> s > > >>> >> > > >>>>>>>>>>> up to the contributor > > >>> >> > > >>>>>>>>>>> s > > >>> >> > > >>>>>>>>>>> to either open a GH PR or upload the patch file > > >>> >> > > >>>>>>>>>>> to JIRA. In fact, Github allows the access to a > > raw > > >>> >> patch > > >>> >> > or > > >>> >> > > >>>>>>> diff, > > >>> >> > > >>>>>>>>> it's > > >>> >> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff" > > >>> suffix to > > >>> >> the > > >>> >> > > >>> end > > >>> >> > > >>>>>>> of > > >>> >> > > >>>>>>>>> the > > >>> >> > > >>>>>>>>>>> Pull Request URL. > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> +1 about having a 'paper trail' > > >>> >> > > >>>>>>>>>>> of review comments > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> o > > >>> >> > > >>>>>>>>>>> n JIRA and > > >>> >> > > >>>>>>>>>>> /or > > >>> >> > > >>>>>>>>>>> mailing list (I > > >>> >> > > >>>>>>>>>>> would > > >>> >> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and > > >>> Flavio > > >>> >> > pointed > > >>> >> > > >>>>>>> out, > > >>> >> > > >>>>>>>> I > > >>> >> > > >>>>>>>>>>> never seen > > >>> >> > > >>>>>>>>>>> GH > > >>> >> > > >>>>>>>>>>> PR review > > >>> >> > > >>>>>>>>>>> ** > > >>> >> > > >>>>>>>>>>> comments > > >>> >> > > >>>>>>>>>>> ** > > >>> >> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka, > > >>> >> Cassandra > > >>> >> > > >>>>>>>>>>> or > > >>> >> > > >>>>>>>>>>> Solr projects > > >>> >> > > >>>>>>>>>>> , that I have followed more closely. > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> Eddie > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han < > > >>> >> > h...@cloudera.com > > >>> >> > > >>>> > > >>> >> > > >>>>>>>> wrote: > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all > get > > >>> sent > > >>> >> to > > >>> >> > > >>> the > > >>> >> > > >>>>>>>>> mailing > > >>> >> > > >>>>>>>>>>>> list or recorded in jira > > >>> >> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need > > to > > >>> keep > > >>> >> > > >>> certain > > >>> >> > > >>>>>>>>> paper > > >>> >> > > >>>>>>>>>>>> trail regarding activities and comments on ASF > side > > >>> >> (JIRA or > > >>> >> > > >>> mail > > >>> >> > > >>>>>>>>> list). > > >>> >> > > >>>>>>>>>>>> Infra page said: > > >>> >> > > >>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed, > > >>> reopened or > > >>> >> > > >>>>>>>>> **commented** > > >>> >> > > >>>>>>>>>>>> on now gets recorded on the project's mailing > list > > >>> >> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or > > >>> >> *comments* on > > >>> >> > > >>> PRs > > >>> >> > > >>>>>>>>> that > > >>> >> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update > on > > >>> that > > >>> >> > > >>> specific > > >>> >> > > >>>>>>>>>> ticket > > >>> >> > > >>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I > > don't > > >>> see > > >>> >> any > > >>> >> > > >>> of > > >>> >> > > >>>>>>> the > > >>> >> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA, > > >>> except > > >>> >> the > > >>> >> > > >>>>>>>> activities > > >>> >> > > >>>>>>>>>> (open > > >>> >> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been > > >>> using > > >>> >> > github > > >>> >> > > >>> for > > >>> >> > > >>>>>>> a > > >>> >> > > >>>>>>>>>> while I > > >>> >> > > >>>>>>>>>>>> assume such practice of NOT integrating comments > > >>> between > > >>> >> > > >>> github > > >>> >> > > >>>>>>> and > > >>> >> > > >>>>>>>>> ASF > > >>> >> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be > > really > > >>> >> useful > > >>> >> > if > > >>> >> > > >>>>>>>>> comments > > >>> >> > > >>>>>>>>>>>> could converge in a single place as well, that > will > > >>> >> provide > > >>> >> > a > > >>> >> > > >>>>>>> clear > > >>> >> > > >>>>>>>>>> history > > >>> >> > > >>>>>>>>>>>> for a given technical issue. > > >>> >> > > >>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio > Junqueira < > > >>> >> > > >>>> f...@apache.org > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>>>>> wrote: > > >>> >> > > >>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 < > https://issues.apache.org/ > > >>> >> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597> > > >>> >> > > >>>>>>>>>>>>> is fixed, we can't merge via github. > > >>> >> > > >>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the > > >>> >> > > >>>>>>>>>> opening/closing/commenting > > >>> >> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in > > >>> jira. I > > >>> >> > don't > > >>> >> > > >>>>>>> think > > >>> >> > > >>>>>>>>> we > > >>> >> > > >>>>>>>>>>>> have > > >>> >> > > >>>>>>>>>>>>> that yet, but it is possible according to this: > > >>> >> > > >>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_ > > >>> >> > > >>>>>>>>>>>>> integration_between_apache_and < > > >>> >> https://blogs.apache.org/ > > >>> >> > > >>>>>>>>>>>>> infra/entry/improved_integrati > > >>> on_between_apache_and> > > >>> >> > > >>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>> For now, we do need to upload patches and > converge > > >>> using > > >>> >> > > >>> jira. > > >>> >> > > >>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>> I think Eddie has been looking at this process > > >>> trying to > > >>> >> > > >>>>>>> replicate > > >>> >> > > >>>>>>>>> the > > >>> >> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if > > I'm > > >>> >> right. > > >>> >> > > >>>> Kafka > > >>> >> > > >>>>>>>>>> doesn't > > >>> >> > > >>>>>>>>>>>>> send every comment to the mailing list, though, > > but > > >>> I'm > > >>> >> not > > >>> >> > > >>> sure > > >>> >> > > >>>>>>> if > > >>> >> > > >>>>>>>>>>>> that's > > >>> >> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to > > >>> double-check. > > >>> >> > > >>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>> -Flavio > > >>> >> > > >>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han < > > >>> >> h...@cloudera.com> > > >>> >> > > >>>>>>> wrote: > > >>> >> > > >>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> Hi, > > >>> >> > > >>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for > > >>> >> uploading > > >>> >> > > >>>> patches > > >>> >> > > >>>>>>>> and > > >>> >> > > >>>>>>>>>>>>> doing > > >>> >> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen > > >>> recently > > >>> >> there > > >>> >> > > >>> are > > >>> >> > > >>>>>>> git > > >>> >> > > >>>>>>>>>> pull > > >>> >> > > >>>>>>>>>>>>>> requests coming in without associated patch > file > > >>> >> uploaded > > >>> >> > to > > >>> >> > > >>>>>>> JIRA. > > >>> >> > > >>>>>>>>>> I've > > >>> >> > > >>>>>>>>>>>>>> checked > > >>> >> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confl > > >>> uence/display/ZOOKEEPER/ > > >>> >> > > >>>>>>>>> HowToContribute > > >>> >> > > >>>>>>>>>> , > > >>> >> > > >>>>>>>>>>>>>> looks like there is not much change regarding > > patch > > >>> >> > process > > >>> >> > > >>> - > > >>> >> > > >>>> so > > >>> >> > > >>>>>>>>>>>>> presumably > > >>> >> > > >>>>>>>>>>>>>> we still need to generate and upload patch file > > to > > >>> JIRA > > >>> >> > for > > >>> >> > > >>> the > > >>> >> > > >>>>>>>>>> record, > > >>> >> > > >>>>>>>>>>>>>> while using github (maybe in addition of review > > >>> board, > > >>> >> or > > >>> >> > in > > >>> >> > > >>>> the > > >>> >> > > >>>>>>>>>> future > > >>> >> > > >>>>>>>>>>>>>> with gerrit) to do code reviews? > > >>> >> > > >>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward > Ribeiro < > > >>> >> > > >>>>>>>>>>>>> edward.ribe...@gmail.com> > > >>> >> > > >>>>>>>>>>>>>> wrote: > > >>> >> > > >>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/ > > >>> >> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597 > > >>> >> > > >>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable. > > >>> >> > > >>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio > > Junqueira > > >>> < > > >>> >> > > >>>>>>>> f...@apache.org> > > >>> >> > > >>>>>>>>>>>>> wrote: > > >>> >> > > >>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull > > >>> request or > > >>> >> > diff. > > >>> >> > > >>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused. > > >>> >> > > >>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>> -Flavio > > >>> >> > > >>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro < > > >>> >> > > >>>>>>>>> edward.ribe...@gmail.com > > >>> >> > > >>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>> wrote: > > >>> >> > > >>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the > kafka-merge.py > > >>> to > > >>> >> work > > >>> >> > > >>> on ZK > > >>> >> > > >>>>>>>>> repos. > > >>> >> > > >>>>>>>>>>>> I > > >>> >> > > >>>>>>>>>>>>>>>> would > > >>> >> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test > it > > >>> now. > > >>> >> > > >>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will > > >>> create a > > >>> >> > github > > >>> >> > > >>>>>>> repo > > >>> >> > > >>>>>>>>> yet > > >>> >> > > >>>>>>>>>>>>>>> today. > > >>> >> > > >>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/ > > >>> >> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0 > > >>> >> > > >>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that > > you > > >>> can > > >>> >> use > > >>> >> > > >>> diff > > >>> >> > > >>>>>>> or > > >>> >> > > >>>>>>>>>> Meld > > >>> >> > > >>>>>>>>>>>>> to > > >>> >> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the > > >>> original > > >>> >> > file > > >>> >> > > >>>>>>> here: > > >>> >> > > >>>>>>>>>>>>>>>>> https://github.com/apache/ > > >>> >> > kafka/blob/trunk/kafka-merge- > > >>> >> > > >>>> pr.py > > >>> >> > > >>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable > is > > >>> not > > >>> >> used > > >>> >> > > >>>>>>> anywhere > > >>> >> > > >>>>>>>>> in > > >>> >> > > >>>>>>>>>>>> the > > >>> >> > > >>>>>>>>>>>>>>>>> merge script??? > > >>> >> > > >>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>> Cheers, > > >>> >> > > >>>>>>>>>>>>>>>>> Eddie > > >>> >> > > >>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick > > Hunt < > > >>> >> > > >>>>>>>> ph...@apache.org > > >>> >> > > >>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>> wrote: > > >>> >> > > >>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4: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? > > >>> >> > > >>>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which > > includes > > >>> >> "git > > >>> >> > > >>> apply" > > >>> >> > > >>>>>>>> and > > >>> >> > > >>>>>>>>>>>>>>>> specifying > > >>> >> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so > > that > > >>> the > > >>> >> OP > > >>> >> > > >>> gets > > >>> >> > > >>>>>>>>> proper > > >>> >> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself) > > >>> >> > > >>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confl > > >>> uence/display/KAFKA/ > > >>> >> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow > > >>> >> > > >>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>> Patrick > > >>> >> > > >>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>>> 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 > > >>> >> > > >>>>>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>>> -- > > >>> >> > > >>>>>>>>>>>>>> Cheers > > >>> >> > > >>>>>>>>>>>>>> Michael. > > >>> >> > > >>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>> > > >>> >> > > >>>>>>>>>>>> -- > > >>> >> > > >>>>>>>>>>>> Cheers > > >>> >> > > >>>>>>>>>>>> Michael. > > >>> >> > > >>>>>>>>>>>> > > >>> >> > > >>>>>>>>>> > > >>> >> > > >>>>>>>>>> > > >>> >> > > >>>>>>>>> > > >>> >> > > >>>>>>>>> > > >>> >> > > >>>>>>>>> -- > > >>> >> > > >>>>>>>>> Cheers > > >>> >> > > >>>>>>>>> Michael. > > >>> >> > > >>>>>>>>> > > >>> >> > > >>>>>>>> > > >>> >> > > >>>>>>> > > >>> >> > > >>>>> > > >>> >> > > >>>>> > > >>> >> > > >>>> > > >>> >> > > >>>> > > >>> >> > > >>>> -- > > >>> >> > > >>>> Cheers > > >>> >> > > >>>> Michael. > > >>> >> > > >>>> > > >>> >> > > >>> > > >>> >> > > >> > > >>> >> > > >> > > >>> >> > > >> > > >>> >> > > >> -- > > >>> >> > > >> Cheers > > >>> >> > > >> Michael. > > >>> >> > > >> > > >>> >> > > > > > >>> >> > > > > > >>> >> > > > > > >>> >> > > > -- > > >>> >> > > > Cheers > > >>> >> > > > Michael. > > >>> >> > > > > >>> >> > > > > >>> >> > > > >>> >> > > >>> > > > >>> > > >> > > >> > > > > > >
