On 22/01/18 21:37, Martin Grigorov wrote: > Hi Mark, > > On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas <ma...@apache.org> wrote: > >> The plan when we migrate to git is to migrate to single git repo with >> the following branches: >> >> master - 9.0.x development >> tc8.5 - 8.5.x development >> tc8.0 - 8.0.x development >> tc7.0 - 7.0.x development >> >> We need to decide how we are going to handle a fix that applies to >> multiple versions. >> >> I can see two options: >> >> 1. Make the change in master and cherry-pick as required to earlier >> versions. This is, essentially, what we do now in svn. >> > > I think this will not work. > "git merge" needs to know the common parent of the two HEADs to be able to > decide what to merge. > I am not sure how smart svn-to-git is these days but I doubt it will be > that smart.
If by "this" in "this will not work" you mean forward merging, we can make this work if we want to based on my limited testing. It requires a few extra commits to get the meta-data to the point where git thinks all previous changes have been merged. From that point it should work (with the odd merge conflict, as now). The tricky part for me is new features. These naturally get implemented against master and then we decide how far back to port them. That requires a new way of thinking if we do forward merging. > Wicket was also converted several years ago from SVN to Git and there we > use cherry-picking. That seems the obvious choice but I'm wary of taking the "that is how we have always done it in svn" approach if there is a better way in git - especially if I don't know about it. > For smaller projects which were started with Git I use git merge! > For feature branches (at work) I even use "git rebase" insteaf of merge. > But this also means you have to use "git push --force" to the remote of the > feature branch. But for feature branches this usually is OK. Feature branches is almost a whole other question but probably one that needs to be discussed on this thread. Mark > > >> >> 2. Make the change in the earliest applicable version and them merge >> forward. This appears to be the more natural git way of doing things. >> >> These options are based on my fairly limited understanding of git. >> Suggestions for other approaches welcome. >> >> Thoughts? Comments? >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
