Re: git commits on JIRA issues;

FYI as of March 15th (10 days now), commits to branches following the pattern (lucene|solr).* (i.e. that which start with "lucene" or "solr") will *not* get an automated comment on corresponding JIRA issues. All others continue to. INFRA got this done for us:

Re: git commits on JIRA issues;

+1 I'll do it. On Wed, Feb 3, 2016 at 3:29 PM Mark Miller wrote: > Yeah man, ugly noise. I think we should open a JIRA to discuss with INFRA > anyway. At a minimum, we should be able to specify which main branches we > care about. Creating noise for everyone's random work

Re: git commits on JIRA issues;

https://issues.apache.org/jira/browse/INFRA-11198 I don't think this has to do with some branches being more significant than others. I think it has to do with the fact that the commit has occurred multiple times (same hash); we just care about the first chronologically. Any way; further

Re: git commits on JIRA issues;

Thanks for creating the issue David. I did not mean to suggest we shouldn't try, only that I think it will be an uphill battle. But i would be very happy if something comes of it! On Wed, Feb 3, 2016 at 1:39 PM, Mark Miller wrote: > It just depends on what behavior you

Re: git commits on JIRA issues;

It just depends on what behavior you want. Some could argue that for certain 'official feature branches' they want this behavior and for random WIP branches they don't. Given the script INFRA uses is for all the projects, if they object to letting us only get the original commits, it's just

Re: git commits on JIRA issues;

Yeah man, ugly noise. I think we should open a JIRA to discuss with INFRA anyway. At a minimum, we should be able to specify which main branches we care about. Creating noise for everyone's random work branches is crazy. - Mark On Wed, Feb 3, 2016 at 3:09 PM david.w.smi...@gmail.com <

Re: git commits on JIRA issues;

: https://issues.apache.org/jira/browse/INFRA-11198 : I don't think this has to do with some branches being more significant than : others. I think it has to do with the fact that the commit has occurred : multiple times (same hash); we just care about the first chronologically. : Any way;

Re: git commits on JIRA issues;

> unless i'm missing something, only getting email/jira > notifications the first time a specific commit was seen would mean that > when backporting from master to 5x (or 6x down the road) there would be no > tracking email/comment ... which would make it much harder to know when > things were

Re: git commits on JIRA issues;

Right; I can't imagine any of us actually trying to merge master to branch_whatever. We cherry-pick. Nobody has dissented on that to my knowledge. ~ David On Wed, Feb 3, 2016 at 8:19 PM Ryan Ernst wrote: > > Are you sure *all* back porting will be done by cherry picking? > >

Re: git commits on JIRA issues;

You can just as easily merge form another branch to master and we want that commit message. Also, there are certainly dissenters of cherry picking, a little Google shows the arguments. Some do not believe in cherry picking at all, it's certainly not a required operation. If anyone got consensus

Re: git commits on JIRA issues;

: > unless i'm missing something, only getting email/jira : > notifications the first time a specific commit was seen would mean that : > when backporting from master to 5x (or 6x down the road) there would be no : > tracking email/comment ... which would make it much harder to know when : >

Re: git commits on JIRA issues;

> Are you sure *all* back porting will be done by cherry picking? Using merge commits for backporting would require resolving all differences between master and the stable branch. From what I've seen, using merge commits between two long lived branches usually happens in other projects by forward

Re: git commits on JIRA issues;

There was 0 consensus from my perspective as well. Some projects make a new branch and merge changes from it. You can do so many myriad of things, which is why most projects come to guidelines and agreement on an approach, but we seem to have some contributors of the mindset that if the new tool

Re: git commits on JIRA issues;

: by forward porting, not backporting. I thought this was pointed out (that : cherry picking is really the only way to backport) in an earlier git : thread, but I could be wrong. I will take your word for it. (I ignored most of the early "if/when/should/why" threads about switching to git

Re: git commits on JIRA issues;

Ok thanks. It's too bad it's not going to be changed. IMO, I don't these extra commit notifications are helpful beyond the original appearance of a given commit. ~ David On Tue, Feb 2, 2016 at 10:52 PM Ryan Ernst wrote: > By the way, I meant I attended a talk *about git at

Re: git commits on JIRA issues;

By the way, I meant I attended a talk *about git at apache* On Feb 2, 2016 19:50, "Ryan Ernst" wrote: > This is expected, as merging in the commit to a branch does create a new > commit for that branch (or rather it is then visible in the history of that > branch while before it

Re: git commits on JIRA issues;

This is expected, as merging in the commit to a branch does create a new commit for that branch (or rather it is then visible in the history of that branch while before it was not). Two years ago at ApacheCon I attended a talk by David Nalley. This issue was brought up, and I spoke a little with