Re: git commits on JIRA issues;

[David Smiley]

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:
https://issues.apache.org/jira/browse/INFRA-11198

I could have asked for a "jira" prefix too but leaving it this ways
encourages consistent branch naming that has been the most prevalent to
date.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[david.w.smi...@gmail.com]

+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 branches is crazy.
>
> - Mark
>
> On Wed, Feb 3, 2016 at 3:09 PM david.w.smi...@gmail.com <
> david.w.smi...@gmail.com> wrote:
>
>> 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 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 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 him afterwards about it. At
 that time, infra had no plans to change anything about how the alerts
 worked.
 On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
 david.w.smi...@gmail.com> wrote:

> I noticed something different today about the bot that posts git
> commits to applicable JIRA issues.  I recently worked on SOLR-7968 -- 
> super
> simple with 2 commits, one for master and one for branch_5x.  I promptly
> saw a comment appear after each commit.  But then today, to my surprise, I
> got notified of a new comment from this bot on this issue that was not
> triggered by an action on my part.:
>
>
> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>
> Notice it's for a branch master-solr-8621.  Christine apparently
> created the branch, did some work, and then brought it up to date with
> master.  That must have caused this commit.  Does anyone know if the ASF 
> or
> whoever knows about this and perhaps is working to fix it?  I'm sure the
> coding of the bot could be improved to account for this situation; there
> seems to be enough metadata to differentiate.
>
> ~ David
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
 --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
> --
> - Mark
> about.me/markrmiller
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[david.w.smi...@gmail.com]

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 discussion of our theories on how to fix it should happen
on the issue.

On Wed, Feb 3, 2016 at 3:42 PM david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:

> +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 branches is crazy.
>>
>> - Mark
>>
>> On Wed, Feb 3, 2016 at 3:09 PM david.w.smi...@gmail.com <
>> david.w.smi...@gmail.com> wrote:
>>
>>> 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 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 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 him afterwards about it. 
> At
> that time, infra had no plans to change anything about how the alerts
> worked.
> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
> david.w.smi...@gmail.com> wrote:
>
>> I noticed something different today about the bot that posts git
>> commits to applicable JIRA issues.  I recently worked on SOLR-7968 -- 
>> super
>> simple with 2 commits, one for master and one for branch_5x.  I promptly
>> saw a comment appear after each commit.  But then today, to my surprise, 
>> I
>> got notified of a new comment from this bot on this issue that was not
>> triggered by an action on my part.:
>>
>>
>> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>>
>> Notice it's for a branch master-solr-8621.  Christine apparently
>> created the branch, did some work, and then brought it up to date with
>> master.  That must have caused this commit.  Does anyone know if the ASF 
>> or
>> whoever knows about this and perhaps is working to fix it?  I'm sure the
>> coding of the bot could be improved to account for this situation; there
>> seems to be enough metadata to differentiate.
>>
>> ~ David
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>> --
>> - Mark
>> about.me/markrmiller
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[Ryan Ernst]

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 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 another another legitimate option one would want that more fits with
> the idea of they apparently think this should work. Which is why I say, "at
> a minimum" we should have this option.
>
> - Mark
>
> On Wed, Feb 3, 2016 at 4:01 PM david.w.smi...@gmail.com <
> david.w.smi...@gmail.com> wrote:
>
>> 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 discussion of our theories on how to fix
>> it should happen on the issue.
>>
>> On Wed, Feb 3, 2016 at 3:42 PM david.w.smi...@gmail.com <
>> david.w.smi...@gmail.com> wrote:
>>
>>> +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 branches
 is crazy.

 - Mark

 On Wed, Feb 3, 2016 at 3:09 PM david.w.smi...@gmail.com <
 david.w.smi...@gmail.com> wrote:

> 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 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 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 him afterwards about 
>>> it. At
>>> that time, infra had no plans to change anything about how the alerts
>>> worked.
>>> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
>>> david.w.smi...@gmail.com> wrote:
>>>
 I noticed something different today about the bot that posts git
 commits to applicable JIRA issues.  I recently worked on SOLR-7968 -- 
 super
 simple with 2 commits, one for master and one for branch_5x.  I 
 promptly
 saw a comment appear after each commit.  But then today, to my 
 surprise, I
 got notified of a new comment from this bot on this issue that was not
 triggered by an action on my part.:


 https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982

 Notice it's for a branch master-solr-8621.  Christine apparently
 created the branch, did some work, and then brought it up to date with
 master.  That must have caused this commit.  Does anyone know if the 
 ASF or
 whoever knows about this and perhaps is working to fix it?  I'm sure 
 the
 coding of the bot could be improved to account for this situation; 
 there
 seems to be enough metadata to differentiate.

 ~ David
 --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 http://www.solrenterprisesearchserver.com

>>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
 --
 - Mark
 about.me/markrmiller

>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
> --
> - Mark
> about.me/markrmiller
>

Re: git commits on JIRA issues;

[Mark Miller]

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 another another legitimate option one would want that more fits with
the idea of they apparently think this should work. Which is why I say, "at
a minimum" we should have this option.

- Mark

On Wed, Feb 3, 2016 at 4:01 PM david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:

> 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 discussion of our theories on how to fix
> it should happen on the issue.
>
> On Wed, Feb 3, 2016 at 3:42 PM david.w.smi...@gmail.com <
> david.w.smi...@gmail.com> wrote:
>
>> +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 branches
>>> is crazy.
>>>
>>> - Mark
>>>
>>> On Wed, Feb 3, 2016 at 3:09 PM david.w.smi...@gmail.com <
>>> david.w.smi...@gmail.com> wrote:
>>>
 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 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 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 him afterwards about it. 
>> At
>> that time, infra had no plans to change anything about how the alerts
>> worked.
>> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
>> david.w.smi...@gmail.com> wrote:
>>
>>> I noticed something different today about the bot that posts git
>>> commits to applicable JIRA issues.  I recently worked on SOLR-7968 -- 
>>> super
>>> simple with 2 commits, one for master and one for branch_5x.  I promptly
>>> saw a comment appear after each commit.  But then today, to my 
>>> surprise, I
>>> got notified of a new comment from this bot on this issue that was not
>>> triggered by an action on my part.:
>>>
>>>
>>> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>>>
>>> Notice it's for a branch master-solr-8621.  Christine apparently
>>> created the branch, did some work, and then brought it up to date with
>>> master.  That must have caused this commit.  Does anyone know if the 
>>> ASF or
>>> whoever knows about this and perhaps is working to fix it?  I'm sure the
>>> coding of the bot could be improved to account for this situation; there
>>> seems to be enough metadata to differentiate.
>>>
>>> ~ David
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>> --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 http://www.solrenterprisesearchserver.com

>>> --
>>> - Mark
>>> about.me/markrmiller
>>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
-- 
- Mark
about.me/markrmiller

Re: git commits on JIRA issues;

[Mark Miller]

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 <
david.w.smi...@gmail.com> wrote:

> 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 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 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 him afterwards about it. At that
>>> time, infra had no plans to change anything about how the alerts worked.
>>> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
>>> david.w.smi...@gmail.com> wrote:
>>>
 I noticed something different today about the bot that posts git
 commits to applicable JIRA issues.  I recently worked on SOLR-7968 -- super
 simple with 2 commits, one for master and one for branch_5x.  I promptly
 saw a comment appear after each commit.  But then today, to my surprise, I
 got notified of a new comment from this bot on this issue that was not
 triggered by an action on my part.:


 https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982

 Notice it's for a branch master-solr-8621.  Christine apparently
 created the branch, did some work, and then brought it up to date with
 master.  That must have caused this commit.  Does anyone know if the ASF or
 whoever knows about this and perhaps is working to fix it?  I'm sure the
 coding of the bot could be improved to account for this situation; there
 seems to be enough metadata to differentiate.

 ~ David
 --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 http://www.solrenterprisesearchserver.com

>>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
-- 
- Mark
about.me/markrmiller

Re: git commits on JIRA issues;

[Chris Hostetter]

: 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 discussion of our theories on how to fix it should happen
: on the issue.

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 backported.

given a coice between the two, i'd much rather see additional 
emails/comments for merges to WIP branches then be confused about if/when 
something was backported (yes you can go search the git logs for 
definitive info, but jira comments like that can save a lot of time when 
trying to answer some questions(.


: 
: On Wed, Feb 3, 2016 at 3:42 PM david.w.smi...@gmail.com <
: david.w.smi...@gmail.com> wrote:
: 
: > +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 branches is crazy.
: >>
: >> - Mark
: >>
: >> On Wed, Feb 3, 2016 at 3:09 PM david.w.smi...@gmail.com <
: >> david.w.smi...@gmail.com> wrote:
: >>
: >>> 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 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 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 him afterwards about 
it. At
: > that time, infra had no plans to change anything about how the alerts
: > worked.
: > On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
: > david.w.smi...@gmail.com> wrote:
: >
: >> I noticed something different today about the bot that posts git
: >> commits to applicable JIRA issues.  I recently worked on SOLR-7968 -- 
super
: >> simple with 2 commits, one for master and one for branch_5x.  I 
promptly
: >> saw a comment appear after each commit.  But then today, to my 
surprise, I
: >> got notified of a new comment from this bot on this issue that was not
: >> triggered by an action on my part.:
: >>
: >>
: >> 
https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
: >>
: >> Notice it's for a branch master-solr-8621.  Christine apparently
: >> created the branch, did some work, and then brought it up to date with
: >> master.  That must have caused this commit.  Does anyone know if the 
ASF or
: >> whoever knows about this and perhaps is working to fix it?  I'm sure 
the
: >> coding of the bot could be improved to account for this situation; 
there
: >> seems to be enough metadata to differentiate.
: >>
: >> ~ David
: >> --
: >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
: >> http://www.solrenterprisesearchserver.com
: >>
: > --
: >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
: >>> http://www.solrenterprisesearchserver.com
: >>>
: >> --
: >> - Mark
: >> about.me/markrmiller
: >>
: > --
: > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
: > http://www.solrenterprisesearchserver.com
: >
: -- 
: Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
: http://www.solrenterprisesearchserver.com
: 

-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: git commits on JIRA issues;

[Ryan Ernst]

> 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 backported.
>

I don't think that is true, since backporting would be done with
cherry-pick, which actually creates a new commit (and thus a different
hash). This issue is about the *same* hash appearing on multiple branches
through merge commits.

Re: git commits on JIRA issues;

[david.w.smi...@gmail.com]

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?
>
> 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 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.
>
> On Wed, Feb 3, 2016 at 5:06 PM, Chris Hostetter 
> wrote:
>
>>
>> : > 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 backported.
>>
>> : I don't think that is true, since backporting would be done with
>> : cherry-pick, which actually creates a new commit (and thus a different
>> : hash). This issue is about the *same* hash appearing on multiple
>> branches
>> : through merge commits.
>>
>> Are you sure *all* back porting will be done by cherry picking?
>>
>> I don't rememebr seeing any clear cut concensus on that to make me
>> comfortable with taking it for granted in the context of this discussion.
>>
>>
>>
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[Mark Miller]

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 on anything from the thread that discussed this I
feel I was reading a different thread.
On Wed, Feb 3, 2016 at 9:25 PM david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:

> 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?
>>
>> 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 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.
>>
>> On Wed, Feb 3, 2016 at 5:06 PM, Chris Hostetter > > wrote:
>>
>>>
>>> : > 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 backported.
>>>
>>> : I don't think that is true, since backporting would be done with
>>> : cherry-pick, which actually creates a new commit (and thus a different
>>> : hash). This issue is about the *same* hash appearing on multiple
>>> branches
>>> : through merge commits.
>>>
>>> Are you sure *all* back porting will be done by cherry picking?
>>>
>>> I don't rememebr seeing any clear cut concensus on that to make me
>>> comfortable with taking it for granted in the context of this discussion.
>>>
>>>
>>>
>>>
>>> -Hoss
>>> http://www.lucidworks.com/
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
-- 
- Mark
about.me/markrmiller

Re: git commits on JIRA issues;

[Chris Hostetter]

: > 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 backported.

: I don't think that is true, since backporting would be done with
: cherry-pick, which actually creates a new commit (and thus a different
: hash). This issue is about the *same* hash appearing on multiple branches
: through merge commits.

Are you sure *all* back porting will be done by cherry picking?

I don't rememebr seeing any clear cut concensus on that to make me 
comfortable with taking it for granted in the context of this discussion.




-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: git commits on JIRA issues;

[Ryan Ernst]

> 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 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.

On Wed, Feb 3, 2016 at 5:06 PM, Chris Hostetter 
wrote:

>
> : > 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 backported.
>
> : I don't think that is true, since backporting would be done with
> : cherry-pick, which actually creates a new commit (and thus a different
> : hash). This issue is about the *same* hash appearing on multiple branches
> : through merge commits.
>
> Are you sure *all* back porting will be done by cherry picking?
>
> I don't rememebr seeing any clear cut concensus on that to make me
> comfortable with taking it for granted in the context of this discussion.
>
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: git commits on JIRA issues;

[Mark Miller]

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
supports something we need to use it to its full expressiveness. The one
way almost all projects don't go with git. Meh.

As far as I'm concerned it's still the Wild West. Although I'm hoping sense
prevails in a natural manner.

Mark
On Wed, Feb 3, 2016 at 8:28 PM Chris Hostetter 
wrote:

>
> : 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 because i didn't want to feel compelled to stick a fork in my eye
> -- but I skimmed enough to get the sense that there was no concensus on
> merge/rebase/cherry-pick strategies.  So i didn't want to fall into an
> assumption on *that* that would cause problems with being able to keep
> track commits in jira -- which i do care about enough to stick a fork in
> my eye, if neccessary, to ensure we don't make a trade off that winds
> up giving up such useful info.)
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Re: git commits on JIRA issues;

[Chris Hostetter]

: 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 because i didn't want to feel compelled to stick a fork in my eye 
-- but I skimmed enough to get the sense that there was no concensus on 
merge/rebase/cherry-pick strategies.  So i didn't want to fall into an 
assumption on *that* that would cause problems with being able to keep 
track commits in jira -- which i do care about enough to stick a fork in 
my eye, if neccessary, to ensure we don't make a trade off that winds 
up giving up such useful info.)


-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: git commits on JIRA issues;

[david.w.smi...@gmail.com]

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 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 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 him afterwards about it. At that
>> time, infra had no plans to change anything about how the alerts worked.
>> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
>> david.w.smi...@gmail.com> wrote:
>>
>>> I noticed something different today about the bot that posts git commits
>>> to applicable JIRA issues.  I recently worked on SOLR-7968 -- super simple
>>> with 2 commits, one for master and one for branch_5x.  I promptly saw a
>>> comment appear after each commit.  But then today, to my surprise, I got
>>> notified of a new comment from this bot on this issue that was not
>>> triggered by an action on my part.:
>>>
>>>
>>> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>>>
>>> Notice it's for a branch master-solr-8621.  Christine apparently created
>>> the branch, did some work, and then brought it up to date with master.
>>> That must have caused this commit.  Does anyone know if the ASF or whoever
>>> knows about this and perhaps is working to fix it?  I'm sure the coding of
>>> the bot could be improved to account for this situation; there seems to be
>>> enough metadata to differentiate.
>>>
>>> ~ David
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[Ryan Ernst]

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 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 him afterwards about it. At that
> time, infra had no plans to change anything about how the alerts worked.
> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" 
> wrote:
>
>> I noticed something different today about the bot that posts git commits
>> to applicable JIRA issues.  I recently worked on SOLR-7968 -- super simple
>> with 2 commits, one for master and one for branch_5x.  I promptly saw a
>> comment appear after each commit.  But then today, to my surprise, I got
>> notified of a new comment from this bot on this issue that was not
>> triggered by an action on my part.:
>>
>>
>> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>>
>> Notice it's for a branch master-solr-8621.  Christine apparently created
>> the branch, did some work, and then brought it up to date with master.
>> That must have caused this commit.  Does anyone know if the ASF or whoever
>> knows about this and perhaps is working to fix it?  I'm sure the coding of
>> the bot could be improved to account for this situation; there seems to be
>> enough metadata to differentiate.
>>
>> ~ David
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>

Re: git commits on JIRA issues;

[Ryan Ernst]

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 him afterwards about it. At that
time, infra had no plans to change anything about how the alerts worked.
On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" 
wrote:

> I noticed something different today about the bot that posts git commits
> to applicable JIRA issues.  I recently worked on SOLR-7968 -- super simple
> with 2 commits, one for master and one for branch_5x.  I promptly saw a
> comment appear after each commit.  But then today, to my surprise, I got
> notified of a new comment from this bot on this issue that was not
> triggered by an action on my part.:
>
>
> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>
> Notice it's for a branch master-solr-8621.  Christine apparently created
> the branch, did some work, and then brought it up to date with master.
> That must have caused this commit.  Does anyone know if the ASF or whoever
> knows about this and perhaps is working to fix it?  I'm sure the coding of
> the bot could be improved to account for this situation; there seems to be
> enough metadata to differentiate.
>
> ~ David
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>