tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grigorov <mgrigo...@apache.org>
Subject Re: [Git migration] Merge strategy
Date Tue, 23 Jan 2018 07:45:30 GMT
On Mon, Jan 22, 2018 at 10:45 PM, Mark Thomas <markt@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 <markt@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message