Git Merge conflict com.kms.katalon.composer.testcase.properties

staff-19

#1

Ever since Katalon’s recent update to version 6.0.5 I can no longer merge our changes. We each have our own branch and will merge up into a master. However everytime a git merge is attempted we are now getting this error:

Auto-merging settings/internal/com.kms.katalon.composer.testcase.properties
CONFLICT (content): Merge conflict in settings/internal/com.kms.katalon.composer.testcase.properties

I have no idea how to resolve this…


#2

$ git pull
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
From https://codecloud.web.att.com/scm/st_nmic/automation_nmic
8aef845…b1276ed Development -> origin/Development
error: Your local changes to the following files would be overwritten by merge:
settings/internal/com.kms.katalon.composer.testcase.properties
Please commit your changes or stash them before you merge.
Aborting
Updating 26f4db5…b1276ed

Is this the error you getting ?


#3

no like the above, here is a screenshot of git bash


#4

Looks like the problem with “settings/internal/com.kms.katalon.composer.testcase.properties”
Is that the time stamp which is a comment at the top keeps changing everyday. This is causing a merge conflict…would ignoring this in git cause an issue?

Looks like this:

by force updating the first line I was able to merge again. If I ignore and the testCaseTag stuff changes, is this going to cause issues? I’m not sure when this file was added but I never had merge conflicts on this until the most recent version of katalon.


#5

I have this same error. One thing you can do it right click and choose “Replace with HEAD Revision”. Then go ahead and commit. BUT, you dont get the latest timestamped version. That will only matter if you make a change like a P1,P2 label or something similar and you actually WANT that change in the settings. I am still waiting for a Katalon explanation. I would like it to simply disregard the datestamp as a valid change.


#6

You should insert the following line into your .gitignore file:

settings/

And you want to remove the files under the settings directory out of the repository by

$ cd $projectDir
$ git rm -r --cached settings

Then you will have no more conflicts of the contents under the settings directory.


#7

I was actually thinking about doing that, that is not gonna cause any issues is it? like do I need the other line from that file for any reason?


#8

I think it is harmless. I think that the settings directory is intentended TO BE IGNORED by Git.

Why do I think so? What is my reason to be confident? Please have a look at the following issue.

In Dec 2018 I experienced Merge conflicts. I investigated it and proposed a fix to Katalon Team. They took my points and changed Katalon Studio a bit. They introduced the settings directory where timestamp-sort of ‘changing every time test runs’ data is stored, and these data are intended to be ignored, I believe.


@Katalon team,

I would like you to state that the settings directory should be .gitignored.


#9

Im new to automation and have been using Katalon for only a few weeks. I’m not using any local Git repo and so Im not sure how to edit it by adding the settings/ comment you mentioned above. Is there a way through Katalon to do this? I would expect a right-click option to add it to the ignored files, but there isnt one.


#10

zbeck008,

c/c @Dung_Ngo, @devalex88

Good question!

It may be surprising but Katalon Studio does NOT provide any means for you to edit .gitignore file located in the project directory. You have to use other text editor of your choice (Note pad, Atom, emacs, vim, etc).


#11

I have ever posted some in this Forum asking Katalon Team to let me edit .gitigore and README.md files.

Katalon team listed this requirement into their back log.

but there seems to be no progress yet.


#12

I don’t agree that ignoring the settings directory is harmless. If you use certain settings like quitting the browser after test case execution or analytics then all of this information is lost when repo’s are cloned/pulled. I am the main person developing scripts and I want everyone to get the settings that I intend for everyone to use with each clone or pull.

With that said, it seems very odd that these files require a date/time stamp as a comment inside the file when the system already stores this data.


#13

I would take your point.

Whether to write settings/ in the .gitignore file — it depends on each uses’ cases.

Once @devalex88 wrote

then we should check whether the .gitignore in the project template in 6.4.0 includes settings/ or not.