From 5f7036d0a71a007ac7261f1af7f94f7e1b661c63 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Wed, 23 Oct 2019 16:32:37 +0000 Subject: [PATCH 1/3] Added a comment: searching by inode --- .../comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment diff --git a/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment b/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment new file mode 100644 index 0000000000..87ff161d66 --- /dev/null +++ b/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="searching by inode" + date="2019-10-23T16:32:37Z" + content=""" +\"there is not an index to make queries for inodes be fast\" -- you'd only need to query for inodes in case of a rename, and only if the rename didn't use `git mv`. So if adding a db index is non-trivial (requires v8?), maybe it's ok if this case is slow? Also, the git index has the [inode](https://github.com/git/git/blob/master/Documentation/technical/index-format.txt#L60) info and other `stat(2)` info preserved by a rename, and you'd only need to check index entries where the working copy file has disappeared; or maybe a [wmemchr()](https://hackage.haskell.org/package/bindings-0.1/docs/src/Bindings-StandardC.html#line-722) through the index would be fast enough? +"""]] From bdf6d2eb48b76b218f66f2a01608aeedfd878162 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Wed, 23 Oct 2019 17:05:42 +0000 Subject: [PATCH 2/3] Added a comment: preventing `git add` from annexing new files --- ...mment_3_c64efa42f8dd8c319bef86c038f8518c._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_c64efa42f8dd8c319bef86c038f8518c._comment diff --git a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_c64efa42f8dd8c319bef86c038f8518c._comment b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_c64efa42f8dd8c319bef86c038f8518c._comment new file mode 100644 index 0000000000..1ce6c180bc --- /dev/null +++ b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_c64efa42f8dd8c319bef86c038f8518c._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="preventing `git add` from annexing new files" + date="2019-10-23T17:05:41Z" + content=""" +\"if that were implemented, I suspect that demand for such a config might dry up\" -- not quite. I'd still want to use `git add` for adding to git and `git annex add` for adding to the annex. It's [[simple|forum/lets_discuss_git_add_behavior/#comment-065d2ab55fe0683a3c186df9211fd522]], so less error-prone; it's compatible with v5 and has worked well there; it lets me avoid accidentally annexing files as unlocked, where one can't see they're annexed by looking at the dir. `git add` re-annexing already-annexed files doesn't involve these concerns: the file had to have been deliberately annexed *and* deliberately unlocked at some point prior, before `git add` will (re-)add it as annexed and unlocked. + +So, I may want to configure `annex.largefiles=anything` and *still* not have `git add` add new files to the annex. + +If you don't want to add a new config setting, maybe, extend the `annex.largefiles` [[syntax|tips/largefiles]] with something like `command=git-add`? +"""]] From 2d33c62965dc30ff62babba25d18547a5aa89e8c Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Wed, 23 Oct 2019 17:57:03 +0000 Subject: [PATCH 3/3] Added a comment: configuring git add behavior --- ...nt_4_aa12a81ca2015945f548d029b720ff33._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_4_aa12a81ca2015945f548d029b720ff33._comment diff --git a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_4_aa12a81ca2015945f548d029b720ff33._comment b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_4_aa12a81ca2015945f548d029b720ff33._comment new file mode 100644 index 0000000000..d7e1e007f2 --- /dev/null +++ b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_4_aa12a81ca2015945f548d029b720ff33._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="configuring git add behavior" + date="2019-10-23T17:57:03Z" + content=""" +Or, could add a variable `annex.git-add-new-largefiles-action`, which determines what `git add` does with files that match `annex.largefiles` but were not already annexed. The possible values would be + + * `git` (default): add to git + * `git-warn`: add to git but print a warning + * `error`: exit with an error code + * `annex`: add to the annex + * `annex-warn`: add to the annex but print a warning + * `annex-autolock`: add to the annex but mark them to be [[auto-locked|todo/auto-lock_files_after_one_edit]] when committed. +"""]]