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