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)
