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:
Ilya_Shlyakhter 2019-09-20 15:43:39 +00:00 committed by admin
parent 0558c6de79
commit deea71d7aa
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/forum/lets_discuss_git_add_behavior/comment_4_d710e5490b9cd3e146ac7acc52311186._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 4"
date="2019-09-20T15:43:39Z"
content="""
Another reason it's not always \"preferable for the mistake to be adding the file content to the annex, vs adding the file content to git\", is that adding it as *unlocked* annexed files can cause [[slowness|bugs/git_status_extremely_slow_with_v7]], can cause files to be unexpectedly missing from new clones until they're explicitly [[gotten|git-annex-get]], etc. The tradeoffs depend on the use case.
\"Suppose you have an unlocked file in your repo, and you rename it\" -- maybe, git-annex could keep track of local unlocked files by inode, not just by path name?
\"The best way seems to be for git-annex to somehow be able to distinguish between them. And that's what annex.largefiles lets it do\" -- can there be an `annex.largefiles_git_add` variable that, if defined, is used by `git add` but not by [[`git annex add`|git-annex-add]]? Then one can set `annex.largefiles_git_add=nothing` to get the former default behavior, while still controlling `git-annex-add` behavior as before.
"""]]