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 <r...@iernst.net> 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 <hossman_luc...@fucit.org >> > 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
