Git merge conflict only on version tag in pom.xml

A

7

22

Is there a way to avoid merge conflicts in version tag in pom.xml when merging master into a branch? I have quite a few pom files, 80, and all of them have same version which is different from one in master. It's laborious and time-consuming to execute git mergetool for 80 pom files just for a version tag.

Avi answered 30/8, 2012 at 12:46 Comment(2)

I would also recommend, about maven, to have a specific pom for your versions, so that when you change the version, you don't have to update all your files. – Emmer 30/8, 2012 at 13:32

The previous comment does not address the question. It's not to do with dependency versions. It's to do with the version of the software you're building being in the pom.xml file. This is an issue because we're storing metadata about the version in a file that any SCM has to deal with. Merges then become complicated. – Dionisio 25/8, 2015 at 14:36

K

11

What I always do is change the version of the modules using the maven versions plugin, before merging from another branch (with a different version):

mvn versions:set -DnewVersion=1.1 -DgenerateBackupPoms=false

That'll change the version of all the current modules (parent and children) to the one you specify as the newVersion parameter. After changing the version, make a new commit (git commit...) and then do the merge. I've got all of this automated using a Jenkins task, but it shouldn't be difficult to implement it in other ways (e.g. sh script).

Kalat answered 17/10, 2015 at 0:2 Comment(0)

M

8

You probably have a few options. None of which are perfect :-/

1) you can use 'git merge -s ours', but you should only do that when you know you don't need the rest of the changes too.

2) You can also use git rerere, which helps resolve conflicts by memorizing what you did last time. You can enable its usage globally so it always "just works" by setting rerere.enabled. Or you can read the man page and do it by hand as well.

Miasma answered 30/8, 2012 at 13:19 Comment(2)

rerere rocks. In fact, it rocks so much you frequently forget you're using it. – Miasma 31/8, 2012 at 16:31

Option 2) won't work if the version changes in anyway since git rerere recorded the merge conflict resolution. So not really an option IMO. – Volleyball 20/3, 2017 at 12:18

P

2

You could also use a custom merge driver, as in pom-merge-driver. Depending on your workflow you might want to merge pom as a normal file, except treating the project version differently: always take the merging branch version, or make an exception when merging to the develop branch...

Polonaise answered 16/9, 2014 at 7:6 Comment(0)

S

1

Take a look at resolve-maven-version-conflicts.pl. It's a mergetool specifically to resolve pom conflicts. It'll ignore any change where both sides are -SNAPSHOT versions, but leave any other conflicts for further resolution.

Sacaton answered 10/4, 2013 at 13:2 Comment(0)

M

1

I had the same problem and all solutions that i found didn't do it, imo, correct. Finally i wrote a merge driver which only takes care of the project/parent version and only them. No dependency version is changed nor the format of the xml file.

I released it a few minutes ago @ https://github.com/cecom/pomutils. If you have any questions, let me know.

Menstruation answered 11/11, 2014 at 14:19 Comment(1)

The tool got now some more improvements. Now you can also auto resolve property values and it is possible to write your own conflict resolution rule. Have a look :-) – Menstruation 10/1, 2015 at 7:1

E

1

In my case I have some future development to merge into develop:

example: some features in mybranch
mybranch version in pom.xml is: 3.11.0-SNAPSHOT
mybranch was forked before version 3.10.0-SNAPSHOT

To merge the new features into develop and force the pom.xml from the feature branch:

git checkout develop

develop version in pom.xml is still: 3.10.0-SNAPSHOT

git merge mybranch

all pom.xml are in conflicts + eventually some other files.

Take all the pom.xml files (assuming nothing else than version has conflicts)

find -name pom.xml -not -path "**/target*" -exec git co --theirs {} +

I had to resolve some others conflicts like e.g. a deleted sub-project in my new branch before running the find command.

After that, all my pom.xml were in new version and compiling without any issue.

Ebersole answered 31/10, 2018 at 17:16 Comment(0)

E

0

Shouldn't it be as simple as wildcarding pom.xml since all of your versions are the same?

git checkout --ours *pom.xml

Euxenite answered 14/12, 2020 at 19:10 Comment(0)

Recommended topics

Hot tags