On 21/04/2023 00:43, songbird wrote:
Max Nikulin wrote:On 20/04/2023 19:10, songbird wrote:one of the worst design decisions i've come across in the modern era was the lack of git respecting file metadata.i know what all you've written below but it does not apply to what i want or how i use those tools and i consider git broken that it caters to broken tools and intentionally then has to screw up information which i consider both useful and critical to how i do things.
Then I have no idea what you were trying to achieve by your original message.
It is perfectly valid to warn people that git is not an appropriate tool when file attributes audit is involved. I can understand if somebody is pushing you toward git. At the same time I see nothing bad in tracking config files in git.
If you are looking for a backup tool that keeps metadata then it is better to ask it explicitly to to get suggestions like rdiff-backup.
Ignorance may be an excuse, but you said it is not the case. For me it is too much to blame developers with harsh statements concerning design decisions just because a tool was created for different tasks.
Git appeared as a tool for linux kernel, a project that relies on make. Frequent incremental rebuilds are must have for developers. Git has some weak sides, but there is no point to attack its features. Git is a great step forward in comparison to CVS and SVN. Experiments with version control systems and build tools have not seized, likely we will see better ones.
Precise tracking of file attributes can cause troubles for VCS. Various file systems have different set of attributes, incompatible time precision. There is no point to track UIDs at all.
I admit, for reproducible builds that include unprocessed files from repository, git behavior is not perfect.
Do not confuse a conscious design choice (even if it is a trade-off) and wrong selection of a tool that is inappropriate for specific purpose.
Some build systems make decisions based on file hashes, not their modification times. It may require a daemon watching file changes to avoid recalculation of all hashes on each build. So such approach is a kind of trade-off.not a choice i agree with and so i have to work around it for my purposes.
File hash approach is for developers relying on incremental rebuilds and caching of build results. It is a way to avoid changing of mtime on checkout.
P.S. Old version of git FAQ explains taken mtime approach in the same way. Build tools relies of modification time comparison:
https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/Git_FAQ.html#Why_isn.27t_Git_preserving_modification_time_on_files.3F (New one is rather brief https://git-scm.com/docs/gitfaq)