mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment

Browse source
This commit is contained in:
vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717 2018-04-05 21:01:51 +00:00 committed by admin
parent dc6d1ad00f
commit d92ec5c1d6
1 changed files with 15 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717"
nickname="vrs+annex"
avatar="http://cdn.libravatar.org/avatar/74219abcec6eece8e2c9d4351c2c912c"
subject="comment 2"
date="2018-04-05T21:01:51Z"
content="""
I have no opinion about what backend to use. If doing it via the metadata system significantly slows down things though and is generally awkward, why not build a separate subsystem?
I don't know what you mean by \"look over all the merged changes and go off and frob timestamps\", but as long as n is on the order of [number of files changed in the commit], updating n files' timestamps sounds reasonable? There's the question of which timestamp has preference in a merge, but that sounds solvable.
I made this a separate bug because it's a specific design proposal; I consider [[todo/does_not_preserve_timestamps]] a tracking bug/user story.
proposal re [[/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/#comment-2ea94161228f0653917b91d4f999153f]]: File and symlink timestamps, after `git-annex-get` or `git-checkout`, are set to whatever's in the repo and then considered immutable. The user can of course change them with `touch`, but if the file is locked while that happens, that's considered a corruption like editing an object file and will be caught by `git-annex-fsck`.
"""]]