You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2018/01/22 21:16:23 UTC
[Git migration] Merge strategy
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.
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
Re: [Git migration] Merge strategy
Posted by jean-frederic clere <jf...@gmail.com>.
On 22/01/18 22:16, Mark Thomas wrote:
> 1. Make the change in master and cherry-pick as required to earlier
> versions. This is, essentially, what we do now in svn.
That is what most of the github "hosted" projects are doing, so +1 for it.
Additionally it prevents forgetting fixing master...
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Git migration] Merge strategy
Posted by Violeta Georgieva <vi...@apache.org>.
2018-01-22 23:16 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> 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.
+1 cherry-pick
Regard,
Violeta
> 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
>
Re: [Git migration] Merge strategy
Posted by Rainer Jung <ra...@kippdata.de>.
Am 23.01.2018 um 08:48 schrieb Rémy Maucherat:
> 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.
>>
>> 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.
>>
>
> I've not seen 2 being done yet, to be honest.
I think the PHP project works that way.
>> These options are based on my fairly limited understanding of git.
>> Suggestions for other approaches welcome.
>>
>> Thoughts? Comments?
I prefer option 1 as well, but can't judge on git-related pros and cons.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Git migration] Merge strategy
Posted by Rémy Maucherat <re...@apache.org>.
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.
>
> 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.
>
I've not seen 2 being done yet, to be honest.
Rémy
>
> 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
>
>
Re: [Git migration] Merge strategy
Posted by Mark Thomas <ma...@apache.org>.
Thanks for all the input. Consensus appears to be for cherry-picking so
I'll update the wiki page accordingly and move onto the next question.
Mark
On 22/01/18 21:16, Mark Thomas 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.
>
> 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
Re: [Git migration] Merge strategy
Posted by Martin Grigorov <mg...@apache.org>.
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-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
>
>
Re: [Git migration] Merge strategy
Posted by Mark Thomas <ma...@apache.org>.
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-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
Re: [Git migration] Merge strategy
Posted by Martin Grigorov <mg...@apache.org>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [Git migration] Merge strategy
Posted by Huxing Zhang <hu...@apache.org>.
+1 on Option 1.
Our internal Tomcat fork has basically the same structure, and we use option 1.
I can't find an easy way to implement option 2.
On Tue, Jan 23, 2018 at 5:16 AM, 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.
>
> 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
>
--
Best Regards！
Huxing
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org