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

Miscellaneous
1

Problem

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…

2

Your post reminded me of the following post

http://forum.katalon.com/t/why-changes-of-lastrun-info-in-a-ts-file-conflict-how-to-prevent-it/14872

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:

http://forum.katalon.com/t/why-changes-of-lastrun-info-in-a-ts-file-conflict-how-to-prevent-it/14872/3

The problem was fixed.

3

@mwarren04011990

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.

4

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

5

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 README.md, instruct the test dev to run this file to put a stop to the issue.

6

I just ran into this too. I’m using git’s assume-unchanged functionality: Git - git-update-index Documentation

git update-index --assume-unchanged <file>

It’s easy, stays in the repo, but git won’t flag it as having changed.

7

Hi there,

Thank you very much for your topic. Please note that it may take a little while before a member of our community or from Katalon team responds to you.

Thanks!