From ab867a7af92a466cb9622b48fa295bf44785cbf0 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 30 Jan 2017 12:42:02 -0400 Subject: [PATCH] responses --- ..._045f90b5693de55958c6ad1b825cbc9e._comment | 10 ++++++ ..._ead7e348547da0598a82be8d064c0c08._comment | 36 +++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_1_045f90b5693de55958c6ad1b825cbc9e._comment create mode 100644 doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_2_ead7e348547da0598a82be8d064c0c08._comment diff --git a/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_1_045f90b5693de55958c6ad1b825cbc9e._comment b/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_1_045f90b5693de55958c6ad1b825cbc9e._comment new file mode 100644 index 0000000000..b1f3d49b43 --- /dev/null +++ b/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_1_045f90b5693de55958c6ad1b825cbc9e._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2017-01-30T16:07:31Z" + content=""" +> Even if -c annex.largefiles=nothing is used with git add, then git commit commits file into annex. + +I don't reproduce that problem; as long as the file is staged with that -c, +git commit commits what's staged. +"""]] diff --git a/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_2_ead7e348547da0598a82be8d064c0c08._comment b/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_2_ead7e348547da0598a82be8d064c0c08._comment new file mode 100644 index 0000000000..2818c73fbb --- /dev/null +++ b/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_2_ead7e348547da0598a82be8d064c0c08._comment @@ -0,0 +1,36 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2017-01-30T16:11:04Z" + content=""" +What's really going on with `git status`: + +* It runs `git annex smudge --clean` +* That ingests the file into the annex, but does not change what's staged at all. +* When you run `git diff`, it again cleans the file and displays + the difference between what is staged (the unannexed file) and the + cleaned version (the annexed file). +* Notice that if you run `git annex add file12 -c annex.largefiles=nothing` + after this, the file gets staged in non-annexed file, as you'd expect. + +So the only problem I see here is `git annex smudge --clean` +is ingesting a file into the annex when `git status` is not going to +update the working tree to use the pointer to that file. But the clean +hook interface doesn't provide it any way to know why git is asking for a +file to be cleaned, so it has to always do that. + +If this is a small file suitable for being checked into git, the overhead of +having a copy of it in the annex shouldn't matter much, and annex.thin +will even make that copy be a hard link. + +I suppose one way this could be improved is for `git annex smudge --clean` +to check if a file was checked into git as a non-annexed file before, +and then avoid cleaning it at all. But then if someone had a non-annexed +file and it got big and they wanted to add it annexed, such a change +would cause a problem.. + +Or git's smudge/clean interface could be improved so that the clean +filter can know why it's being called, and so avoid ingesting files +unnecessarily. IIRC my patch to improve the git interface did do that, but +unfortunately it's stalled getting accepted into git. +" ""]]