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

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2019-10-23 15:30:55 -04:00
commit 8fb1350a2c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 35 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment Normal file
View file

@ -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?
"""]]

12
doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_c64efa42f8dd8c319bef86c038f8518c._comment Normal file
View file

@ -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`?
"""]]

15
doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_4_aa12a81ca2015945f548d029b720ff33._comment Normal file
View file

@ -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.
"""]]