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

Merge remote-tracking branch 'branchable/master'

Browse source
This commit is contained in:
Joey Hess 2011-03-22 17:54:09 -04:00
commit 3b312a0c2b
7 changed files with 77 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
doc/bugs/Unfortunate_interaction_with_Calibre.mdwn Normal file
View file

@ -0,0 +1,21 @@
# Calibre
Calibre is a somewhat popular eBook management package that's also free software. <http://calibre-ebook.com/>
Install via
# apt-get install calibre
There is a somewhat unfortunate interaction between Calibre and git-annex...
* git-annex makes its files become read-only. By the way, that's not quite obvious from the documentation; I suggest making that more prominent.
* Calibre modifies files (not quite sure of semantics, how, or why) when doing various operations, notably such as when copying a book from one's library to one's portable reading device.
These don't play well together, sadly.
I'd expect most of the issue to sit on the Calibre side, and have reported it as a bug.
[Calibre bug #739045](https://bugs.launchpad.net/calibre/+bug/739045)
Preliminary indication is that they're treating it as a functionality change they'll decline to fix. Which isn't entirely unreasonable - I anticipated as much, and I don't want to treat that as a bad/wrong decision.
However, I think it's:
* Unfortunate, as fitting Calibre together with git-annex seems like a neat idea.
* Useful to make sure that this kind of "doesn't play well together" condition is documented, even if only as a bug report.

12
doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1dbc7ad76._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="praet"
ip="81.242.56.203"
subject="comment 5"
date="2011-03-21T19:58:34Z"
content="""
In the meantime, would it be acceptable to split the pre-commit hook
into two discrete parts?
This would allow to (if preferred) defer \"git annex fix\" until
post-commit while still keeping the safety net for unlocked files.
"""]]

10
doc/bugs/softlink_atime.mdwn
View file

@ -37,3 +37,13 @@ Optionally, editing the meta-data should change the times in all annexes.
git add .metadata
>>>>>> Thanks a lot. Doing this in a new git-annex repo from the start should at least ensure local consistency and I assume I can simply add a post-pull hook to restore the mtimes on all all other repositories? -- RichiH
>>>>>>> This is even better:
#!/bin/sh
git annex pre-commit .
which metastore || echo "$0: metastore is not installed; exiting"; exit 99
metastore --save
git add .metadata
>>>>>>> -- RichiH

8
doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_8_881aecb9ae671689453f6d5d780d844b._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
nickname="Jimmy"
subject="comment 8"
date="2011-03-21T08:52:18Z"
content="""
Just tried building both of the code paths, and they seem to build and somewhat function on OSX. I have yet to confirm the functionality is working correctly, but so far it's looking good. (I somewhat care less about the utimes/mtimes of my files since I care more about the content :) )
"""]]

8
doc/download/comment_1_fbd8b6d39e9d3c71791551358c863966._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://peter-simons.myopenid.com/"
ip="84.189.2.244"
subject="Please provide stable tarballs or zipfiles"
date="2011-03-22T13:06:58Z"
content="""
I'm trying to package git annex for ArchLinux and NixOS. That task would be a *lot* easier, if there were proper release archives available for download. The Gitweb site offers to create snapshot tarballs on the fly, but those tarballs have a different SHA hash every time they're generated, so they cannot be used for the purposes of a distribution. A simple solution for this problem would be to enable snapshots in zip format (because zip files look the same every time they're generated).
"""]]

8
doc/download/comment_2_f85f72b33aedc3425f0c0c47867d02f3._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
nickname="Jimmy"
subject="comment 2"
date="2011-03-22T14:01:37Z"
content="""
maybe snag tarballs from <http://packages.debian.org/experimental/git-annex> ?
"""]]

10
doc/download/comment_3_cf6044ebe99f71158034e21197228abd._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joey.kitenet.net/"
nickname="joey"
subject="comment 3"
date="2011-03-22T18:09:21Z"
content="""
The tarballs produced by gitweb are actually stable. They are wrapped in a gz file with a varying timestamp however. It might be nice if gitweb passed --no-name to gzip to avoid that inconsistency.
git-annex also has a [pristine-tar](http://kitenet.net/~joey/code/pristine-tar/) branch in git that can be used to recreate the tarballs I upload to Debian.
"""]]