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

This commit is contained in:
Joey Hess 2013-08-27 16:21:52 -04:00
commit a597d86bb7
3 changed files with 44 additions and 0 deletions

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://edheil.wordpress.com/"
ip="173.162.44.162"
subject="comment 11"
date="2013-08-27T02:27:08Z"
content="""
Awesome! I'll grab a new nightly in a day or two and give it another shot.
"""]]

View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="konubinix"
ip="82.243.233.186"
subject="And with a lots of mails?"
date="2013-08-27T06:44:56Z"
content="""
Hi,
I have a question quite similar, but for a different purpose. I use OfflineImap for imap synchronisation, but in my current situation, I travel a lot between two places: one connected to the Internet and the other not connected.
When I am connected to the Internet, I may synchronize mails, then I rsync my ~/Mail directory to a usb key so that I have access to them in the place without connection. The mails filenames may be changed as Joeyh mentioned while I read or delete them. I rsync them back to the usb key before going back to the place with Internet connection, where the OfflineImap synchronization may occur.
This solution, with rsynced key, works well. But I would love a history of what was done with file names and may be able to retrieve an old mail.
I figured out that that the git annex was a really good solution for that.
The main drawback from my point of view is that I have around 100 000 mails (some would say that's \"[Not much mail](http://notmuchmail.org/)\"), and I am afraid that git will be quite slow with that amount of files.
Did anyone experience an annexed repository with so many items it in?
Best
"""]]

View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
nickname="Richard"
subject="comment 2"
date="2013-08-27T20:02:23Z"
content="""
If starting commit id _and_ commit id from when history is being dropped are documented, you could potentially drop more data.
* Don't have any commits in common? Full merge?
* Only share the starting ids? Reduce local history as much as possible and then merge.
* Share both starting id and have the last id somewhere in history? Take history from last id up to current, reduce that, and merge.
-- RichiH
"""]]