Re: gitification (was Re: /etc/fstab question (problem)?
Am 22.04.2023 um 08:33 schrieb Max Nikulin:
> 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)
>
>
Thank you, Mr. Nikulin, for writing this long message. I am totally with
you in many regards, and have been following this thread for some time,
mostly wondering and finding myself unable to put into words, what was
bugging me with it. It is quite a challenge to see it the way you (and
i) do, while still being friendly and helpful to the OP. but you managed
that, and i admire the way, you are doing it. Very nice and fine
distinctions like (i'll give one example only: )
>> 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.
Just saying: I do very much appreciate your post. Thank you for that.
DdB
Reply to: