Hi,
I am more interested about the workflow for merging (really *merge*) the stuff from trunk to 5.x! In the current SVN workflow we record the history about that and we see all related commits of this merge (in advanced SVN view), so just applying the same patch to trunk and 5.x (how it looks) is not what we should do. And here, not even svn’s history is linear. So what’s the right way to merge 3 commits from trunk (now master) to branch_5x? Cherry-Pick and the commit and push? I have no idea, really! I just know how to use TortoiseGit and I see many buttons and checkboxes there that I don’t know. :) I want to see that those merges came from trunk/master in history. I agree that merging back feature branches should look like a single commit (in simple cases) and you don’t want to see all work-in-progress-commits like typo fixes, small refactorings, adding javadocs,… For large feature branches where more than one comitter are working on, we should of course keep history and not only the final merge. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: [email protected] From: Ramkumar R. Aiyengar [mailto:[email protected]] Sent: Wednesday, January 20, 2016 9:26 AM To: [email protected] Subject: Re: GIT migration date (SVN freeze) More to Mark's point, the focus of this effort is to move the repo and not the development model. Sure, we can debate a lot more on whether rebase or merge is preferred, bit given that the amount of git experience varies across committers, it would help to start off as close to SVN as possible, and linear history fits the bill.. On 20 Jan 2016 06:30, "Mark Miller" <[email protected] <mailto:[email protected]> > wrote: On Tue, Jan 19, 2016 at 11:51 PM Noble Paul <[email protected] <mailto:[email protected]> > wrote: > Yes, patches in JIRA will still be the primary force, with our secondary > GitHub integration hooks. Agreed, 3rd party submissions will get effectively > squashed anyway. In the Git world users are happy give a pull request instead of a patch. Why do you think patches in Jira will be the primary force? Because we are not changing anything about the current process right now. Just moving from SVN to Git. First class support is still patches in JIRA. We have a second class integration with Github as well. As before, contributors are free to use either. Nothing changes in that regard. - Mark -- - Mark about.me/markrmiller <http://about.me/markrmiller>
