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. Wicket was also converted several years ago from SVN to Git and there we use cherry-picking. 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. > > 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 > >
