On Mon, Jan 22, 2018 at 10:45 PM, Mark Thomas <ma...@apache.org> wrote:
> 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 > Yes, I meant 1). > 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 > >
