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