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