Proposal: rename .tito/tito.props to .tito/props.ini

[Malix-Labs]

Subject

.tito/tito.props

Problem

1. File Extension : It seems to have an ini file format but has a .props file extension (doesn't get highlighted nor linted properly)
2. Redundancy : duplicated "tito"

Solution

Rename it to .tito/props.ini

Workaround

Point 1 only

VSCode

Append these lines to your settings.json :

"files.associations": {
	"tito.props": "ini"
}

[FrostyX]

Hello @Malix-Labs,
thank you for the RFE.

I completely agree with your reasoning and that the .tito/props.ini would be better.
We also have .tito/releasers.conf so .tito/props.conf would be more consistent even though it sounds ridiculous. Personally, I would land at .tito/tito.conf even if there is the mentioned redundancy.

But I am not sure whether it is something worth breaking the backward compatibility for. IMHO it isn't. There are blog posts about Tito that would get outdated, upstream repos would have to migrate to the new config name, etc.

The manual page man tito.props says

Project settings can be stored in files:
GITROOT/.tito/tito.props
GITROOT/SOME/PACKAGE/tito.props

so maybe it will be possible to add a third file to this and let tito init create a symlink from tito.props to the new file to preserve backward compatibility and slowly deprecate the old one. But that again sounds like too much hassle for too little benefit.

What are your thoughts?

[Malix-Labs]

Hello @FrostyX, thanks for your time reading and replying to my issue !

But I am not sure whether it is something worth breaking the backward compatibility for. IMHO it isn't. There are blog posts about Tito that would get outdated, upstream repos would have to migrate to the new config name, etc.

Wouldn't it be possible to make both file work (with a priority order ofc), and to make tito init create the new file names instead?

I think this is the best of both world, and what has worked for most of the project I contribute too, such as VSCode and Vite

so maybe it will be possible to add a third file to this and let tito init create a symlink from tito.props to the new file to preserve backward compatibility and slowly deprecate the old one. But that again sounds like too much hassle for too little benefit.

This is also possible indeed but would perhaps be more work ?
Technically, it might be better indeed

[FrostyX]

Wouldn't it be possible to make both file work (with a priority order ofc), and to make tito init create the new file names instead?

We discussed this on a team meeting, and it should be possible and nobody has anything against it. But I don't have any time to work on this, so you would have to submit a PR with the change.

The only problem with the solution you are proposing is that many documents and blog posts mention .tito/tito.props and they would unnecessarily become outdated once tito init starts creating the new file. So I think tito init should also create .tito/tito.props which would be a symlink to the new file.

[Malix-Labs]

you would have to submit a PR with the change

I unfortunately also have no time for this atm, but that's not an important nor urgent change

If I ever end up using tito very much, I would consider working on this, but that's very improbable

[Malix-Labs]

Sorry, I missclicked on closed as not planned