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

Added a comment: .gitattributes could solve this

Browse source
This commit is contained in:
branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e 2019-09-29 22:59:48 +00:00 committed by admin
parent 774b0ce342
commit 2e1d2bc6d5
1 changed files with 25 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
doc/todo/wishlist__58___disable_automatic_commits/comment_1_3f76bc558b59f90d0276be8cd24c6797._comment Normal file
View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
nickname="branchable"
avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
subject=".gitattributes could solve this"
date="2019-09-29T22:59:48Z"
content="""
Revisiting this topic 3.5 years later ...
The assistant will still commit a change as soon as it notices it. This obviously has the advantage of synchronising changes to peers quicker, but it also has downsides:
- It pollutes the git history with every single (saved) edit.
- Consequently it bloats the git object store.
I find this undesirable even when editing my TODO list, but it could be particularly problematic with large files, e.g. using `ffmpeg` to transcode a video between formats would presumably capture lots of intermediate states of the unfinished transcoding process. Similarly for rendering from a video editor.
So it would be helpful if there was a configurable option to determine how often changes get committed. Ideally this would be configurable via `.gitattributes`, e.g.
```
* annex.autocommit=anything
*.webm annex.autocommit=(mtimebefore=10mins)
```
would autocommit most stuff immediately, but would only autocommit webm files if they haven't changed within the last 10 minutes.
"""]]