You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2019/10/14 20:44:38 UTC
working in git on 2 branches
Hi,
For uimaj project in git, we have 2 "master" branches: the master (which has v3
version of the code), and master-2 (which has the v2 version of the code).
If I commit / push a change to the master, and now want to have the same change
in the v2 version, what's the recommended process to achieve that?
For example, I pushed an update to .gitignore at the uimaj project level (this
has all of the sub projects as subfolders), for v3. I'd like the same change in v2.
I can't say "merge" into v2, because there's lots of code which is different
intentionally...
I want to say merge just this file, or merge just changes after this date, I
think. Or maybe there's another way entirely to do this (e.g. have two local
clones and 2 open Eclipse's and copy the file from one to the other - but this
seems clumsy and error prone)?
Thanks for any advice :-) -Marshall
Re: working in git on 2 branches
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 21. Oct 2019, at 15:47, Marshall Schor <ms...@schor.com> wrote:
>
> The merge with -s own is a great trick! I tried it, and it does what I want, e.g.
> remembers the state of things, so that a future merge just considers deltas from
> that point :-)
Useful hint: when creating a release (with maven) of a maintenance branch, make sure it
is merged to master prior to the release, then after the release merge with `-s own`
to ensure the version updates to the POM do not propagate to master.
Until I discovered "-s ours" the release process had been giving me some serious headaches :)
-- Richard
Re: working in git on 2 branches
Posted by Marshall Schor <ms...@schor.com>.
The merge with -s own is a great trick! I tried it, and it does what I want, e.g.
remembers the state of things, so that a future merge just considers deltas from
that point :-)
This is what I was relying on in SVN merge, to make things "easy". Nice to know
there's a Git equivalent.
Thanks! -Marshall
On 10/14/2019 5:09 PM, Richard Eckart de Castilho wrote:
> Here are two options I have used so far:
>
> == Two PRs
>
> - create one PR against branch "master"
> - create a second PR against "master-legacy-version" into which you cherry-pick the changes from the first PR
>
> == Merging branches (this is the one I usually use)
>
> - this requires that "master" and "master-legacy-version" have some common history
> - tell git that all changes against "master-legacy-version" have been merged into master by calling "git merge -s ours master-legacy-version" on a checked-out "master"
> - create a PR against the "master-legacy-version" and merge it
> - repeat for other PRs if you like
> - merge the "master-legacy-version" into master (or create a PR to do this merge if you cannot push to master directly)
>
> Considering what you write, I think you'd also like to go with option 2. I use option 1 usually only if I accidentally did a bugfix PR against master which should have gone into "master-legacy-version"
>
> For uimaFIT, I have so-far used only option 1 but it is tedious. I'd prefer switching to option 2 at some point.
>
> -- Richard
>
>
Re: working in git on 2 branches
Posted by Richard Eckart de Castilho <re...@apache.org>.
Here are two options I have used so far:
== Two PRs
- create one PR against branch "master"
- create a second PR against "master-legacy-version" into which you cherry-pick the changes from the first PR
== Merging branches (this is the one I usually use)
- this requires that "master" and "master-legacy-version" have some common history
- tell git that all changes against "master-legacy-version" have been merged into master by calling "git merge -s ours master-legacy-version" on a checked-out "master"
- create a PR against the "master-legacy-version" and merge it
- repeat for other PRs if you like
- merge the "master-legacy-version" into master (or create a PR to do this merge if you cannot push to master directly)
Considering what you write, I think you'd also like to go with option 2. I use option 1 usually only if I accidentally did a bugfix PR against master which should have gone into "master-legacy-version"
For uimaFIT, I have so-far used only option 1 but it is tedious. I'd prefer switching to option 2 at some point.
-- Richard