projectFileLocation in the .prj file seems like YAGNI...what can we do about it


For a while, I have been seeing that .prj file in my GitHub pull requests, and every time, it is that Katalon (or some other process) is writing that file’s absolute path to its <projectFileLocation> tag.

Nothing else, ever gets changed about the file.

What I’m thinking (and need help with)

I can think of two things:

  • remove the file from the GitHub repository, or
  • somehow tell Katalon to stop hardcoding the .prj file’s absolute path to the file itself…

I am seeking help on which of these I should do and why…

The former, I can do right now, and is simpler to me, but it means that, if I get another machine (or if I train a peer on the project), try to clone the project repository on to that machine, and try to open it in Katalon Studio, it won’t work.

So, I would like help with the latter…

1 Like

Your post reminded me of the following post

5 years ago, *.ts file (Test Suite definition file) contained <lastRun> element which caused merge conficts very often. It annoyed users a lot.

Later, (a year ?), Katalon removed the <lastRun> element out of the *.ts file:

The problem was fixed.



Are you looking for a way to work arround ?

Why changes of <lastRun> info in a *.ts file conflict --- how to prevent it proposed a tentative workaround to avoid merge conflicts using the .gitattribute file with the clean and the smudge filters. You may find it interesting.

1 Like

I’m going to check that .gitattribute filter out tomorrow… Thank you for, again, providing immense value

I was able to implement the smudge filter thing, but I instead did this as the smudge filter:

[filter "projectFileLocation-in-prj"]
	smudge = sed '/<projectFileLocation>/d'
	clean = sed '/<projectFileLocation>/d'

I did one better: ask Phind AI to write a BASH script to write this into .git/settings for the test dev. I then, in the project, instruct the test dev to run this file to put a stop to the issue.