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