diff options
16 files changed, 428 insertions, 7 deletions
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment new file mode 100644 index 000000000..a6a2397e7 --- /dev/null +++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment @@ -0,0 +1,34 @@ +[[!comment format=mdwn + username="boh" + avatar="http://cdn.libravatar.org/avatar/e7fa2d1c5d95e323fe48887f7f827b1f" + subject="comment 9" + date="2016-11-27T12:23:20Z" + content=""" +Seems as if the problem still exists in 6.20161118 (Debian). + +I have three repositories (among others), `jolla`, `sts-3xx`, and `here`. `jolla` and `here` are in group `manual`, `sts-3xx` is `backup`; `here` and `sts-3xx` have assistants running, `jolla` not. `jolla` and `sts-3xx` have slightly older versions of git-annex installed. + +Now, when I copy a file from `here` to `jolla` like this + + git annex copy real_programmers.png -t jolla + +the file is subsequently dropped by the assistant: + +``` +drop real_programmers.png (locking jolla...) [2016-11-27 13:00:02.667376556] chat: ssh [\"-S\",\".git/annex/ssh/jolla\",\"-o\",\"ControlMaster +=auto\",\"-o\",\"ControlPersist=yes\",\"-F\",\".git/annex/ssh.config\",\"-T\",\"jolla\",\"git-annex-shell 'lockcontent' '/~/Music/media/' '--debug' ' +SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d36380d0e7e8dab468f883.png' --uuid 5298e3ce-1106-4d5e-b052-0aee4b27a344\"] +(locking sts-3xx...) [2016-11-27 13:00:03.252473676] chat: ssh [..., \"git-annex-shell 'lockcontent' '/backups/exot/media/' '--debug' 'SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d 36380d0e7e8dab468f883.png' --uuid 1fec6253-171d-4f86-885b-e233be2d65ec\"] +(lockcontent failed) [2016-11-27 13:00:03.486158016] process done ExitFailure 1 +(checking sts-3xx...) [2016-11-27 13:00:03.487047149] call: ssh [..., \"git-annex-shell 'inannex' '/backups/exot/media/' '--debug' 'SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d363 80d0e7e8dab468f883.png' --uuid 1fec6253-171d-4f86-885b-e233be2d65ec\"] +[2016-11-27 13:00:03.76435136] process done ExitSuccess +[2016-11-27 13:00:03.764705754] Dropping from here proof: Just (SafeDropProof (NumCopies 2) [RecentlyVerifiedCopy UUID \"1fec6253-171d-4 f86-885b-e233be2d65ec\",LockedCopy UUID \"5298e3ce-1106-4d5e-b052-0aee4b27a344\"] (Just (ContentRemovalLock (Key {keyName = \"ff98a733cc012 2858fb11433c720e2d038fec190a3d36380d0e7e8dab468f883.png\", keyBackendName = \"SHA256E\", keySize = Just 84499, keyMtime = Nothing, keyChun kSize = Nothing, keyChunkNum = Nothing})))) +[2016-11-27 13:00:04.24333081] process done ExitFailure 1 +ok +[2016-11-27 13:00:04.251232455] dropped real_programmers.png (from here) (copies now 4) : drop wanted after Upload UUID \"5298e3ce-1106- 4d5e-b052-0aee4b27a344\" real_programmers.png Just 84499 +``` + +However, I failed to reproduce the problem by replicating my setup with fresh repositories … + +Please let me know if you need more information, and *so* many thanks for git-annex! +"""]] diff --git a/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn b/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn new file mode 100644 index 000000000..c9037b575 --- /dev/null +++ b/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn @@ -0,0 +1,53 @@ +### Please describe the problem. + +I'm seeing some inconsistent results between runs of `git annex fsck` and `git annex whereis` that I'm not able to explain. When I run `git annex fsck`, it reports a few keys that only have 1 copy, and advises me to make more copies. If I run `git annex whereis --key <key>`, git annex confirms that it only knows about 1 copy of this key. If I then use `git log --stat -S'<key>'` to find the actual file that it refers to, and run `git annex whereis <file>`, git annex report 9 copies of this file. Checking on remotes shows that these files do exist on the remote, so why does `git annex fsck` and `git annex whereis` mis-report the number of copies when querying for the key - but not for the actual filename? Additionally, `git annex find --lackingcopies 1` doesn't return any results, but should if there are actually files with not enough copies? + + +### What steps will reproduce the problem? + + +### What version of git-annex are you using? On what operating system? + +5.20151208-1build1 on Ubuntu Xenial, one remote running 5.20141024~bpo70+1 on Debian Wheezy + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + +[william@hactar ~/Pictures/Photo Library]$ git annex whereis SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 +git-annex: SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 not found +git-annex: whereis: 1 failed +[william@hactar ~/Pictures/Photo Library]$ git annex whereis --key SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 +whereis SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 (1 copy) + 7691934f-2542-4103-9122-2db4e6cfc887 -- hactar [here] +ok +[william@hactar ~/Pictures/Photo Library]$ git annex fsck --key SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 +fsck SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 + Only 1 of 3 trustworthy copies exist of SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 + Back it up with git-annex copy. +failed +(recording state in git...) +git-annex: fsck: 1 failed +[william@hactar ~/Pictures/Photo Library]$ git log --stat -S'SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9' +[william@hactar ~/Pictures/Photo Library]$ git annex whereis 2009/05/05/P1040890.JPG +whereis 2009/05/05/P1040890.JPG (9 copies) + 0e825a69-1927-4f62-b731-6f3e98bba998 -- william@marvin:/media/backup/annex/photos [marvin] + 1b728ab5-1e32-45a6-bc11-2a4bfdc9d6ab -- backup1 + 5c0caa42-b489-467b-a612-9590fa9d5a94 -- backup2 + 7691934f-2542-4103-9122-2db4e6cfc887 -- hactar [here] + 894b2216-72e0-40e1-8765-1386e1e9e4b4 -- backup3 + 96f19fa8-d385-4e8b-b000-61ee15993a70 -- backup3 + a862b121-d794-4af4-bb56-21adfe8962f2 -- S3 + b083f8ae-42fb-41f0-a2a3-4e7c9f93aadb -- [guide] + bf021ce9-465b-4419-86e7-bddfd208fca4 -- git@newzaphod:~/repositories/annex/photos.git [zaphod] +ok + + +# End of transcript or log. +"""]] + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + +I trust Git Annex to keep hundreds of GB of data safe, and it has never failed me - despite my best efforts diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment new file mode 100644 index 000000000..bf41d40a5 --- /dev/null +++ b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://launchpad.net/~stephane-gourichon-lpad" + nickname="stephane-gourichon-lpad" + avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089" + subject="Known bug, fixed." + date="2016-11-23T18:04:27Z" + content=""" +This is a known bug introduced in 6.20161012 and fixed in 6.20161031. + +Solution is: just update your copy of git-annex. At this time most recent is 6.20161119 . + +For more details, see changelog at https://github.com/joeyh/git-annex/blob/master/CHANGELOG#L53 + + + +"""]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment new file mode 100644 index 000000000..0cafc2a4d --- /dev/null +++ b/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="CandyAngel" + avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" + subject="comment 4" + date="2016-11-25T20:27:07Z" + content=""" +I really don't know what to say. I can't even figure out which computer I updated git-annex on to test if it was still happening.. let alone reproduce it anymore. It does work fine. + +I'm so sorry to bother you with this, I've done something stupid! This is exactly why you ask for a transcript of bugs occurring. (Feel free to use this as an example for why you ask for them, so some good can come of it at least..). +"""]] diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment new file mode 100644 index 000000000..327b63469 --- /dev/null +++ b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment @@ -0,0 +1,30 @@ +[[!comment format=mdwn + username="https://launchpad.net/~felixonmars" + nickname="felixonmars" + avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38" + subject="comment 1" + date="2016-11-28T04:17:12Z" + content=""" +aws has merged a PR to support http-conduit 2.2, but git-annex itself doesn't build with the new component yet: + +``` +[ 95 of 544] Compiling Utility.Url ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o ) + +Utility/Url.hs:354:34: error: + * The constructor `StatusCodeException' should have 2 arguments, but has been given 3 + * In the pattern: StatusCodeException s _ _ + In an equation for `matchStatusCodeException': + matchStatusCodeException want e@(StatusCodeException s _ _) + | want s = Just e + | otherwise = Nothing + +Utility/Url.hs:354:34: error: + * Couldn't match expected type `HttpException' + with actual type `HttpExceptionContent' + * In the pattern: StatusCodeException s _ _ + In an equation for `matchStatusCodeException': + matchStatusCodeException want e@(StatusCodeException s _ _) + | want s = Just e + | otherwise = Nothing +``` +"""]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn new file mode 100644 index 000000000..c1f71789b --- /dev/null +++ b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn @@ -0,0 +1,34 @@ +### Please describe the problem. + +I'm sending a stream of keys and filenames to git-annex fromkey on stdin, and it errors out with "git-annex: <stdin>: hGetContents: invalid argument (invalid byte sequence)". On the other hand yipdw tried to reproduce this and it worked fine for him, so I must be doing something wrong. + +I have LANG=en_US.UTF-8 set in my environment, if that matters. + +### What steps will reproduce the problem? + +[[!format sh """ +echo "MD5-s3263532--0b4d070eff7baa8ef314ca330aecb71f é" | git-annex fromkey +"""]] + +### What version of git-annex are you using? On what operating system? + +[[!format sh """ +git-annex version: 6.20161118-g0a34f08 +build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi +key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL +remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external +local repository version: 5 +supported repository versions: 3 5 6 +upgrade supported from repository versions: 0 1 2 3 4 5 +operating system: linux x86_64 +"""]] + +### Please provide any additional information below. + +Note that this is indeed valid utf-8: + +[[!format sh """ + db48x ~ projects IA.BAK-server echo "é" | hexdump -C +00000000 c3 a9 0a |...| +00000003 +"""]] diff --git a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment new file mode 100644 index 000000000..42550d51f --- /dev/null +++ b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="scottgorlin@a32946b2aad278883c1690a0753241583a9855b9" + nickname="scottgorlin" + avatar="http://cdn.libravatar.org/avatar/2dd1fc8add62bbf4ffefac081b322563" + subject="IgnoreUnknown Include considered harmful?" + date="2016-11-23T20:07:45Z" + content=""" +As noted, include appears to not work on a mac at the moment. This means git-annex silently ignores the included configs, which may be required to ssh to the remotes of interest. This is happening to me. + +My understanding is that ssh aliases are the recommended way of juggling multiple private keys amongst multiple hosts, so it is a required part of many git workflows. In this particular case, I have set up git annex on a NAS which does not allow multiple ssh users (QNAP) and the authentication is done only via key identity, not username. Thus, host aliases are necessary. + +If one config can't include another, I would prefer an early failure indicating a problem with the config file, or better, a solution where git-annex doesn't require a config. In this scenario, git fetch remote_name and git annex copy --to remotename do not resolve to the same alias definitions (the latter is missing because of the ignored config!). + +I got my setup to work only by finding and manually editing <repo>/.git/annex/ssh_config, which to my knowledge is undocumented (ie when is it written? do any commands change it?); manual mucking around inside .git to me is not a good practice, and for now I have two different alias's defined (in repo and in ~/.ssh/config) + + +"""]] diff --git a/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment b/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment new file mode 100644 index 000000000..566926a32 --- /dev/null +++ b/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="palday@91f366b5178879146d2b6e1e53bfa21389ee89a8" + nickname="palday" + avatar="http://cdn.libravatar.org/avatar/077a63af75ddba159980fbf88690f401" + subject="Temporary workaround until the brew formula is updated" + date="2016-11-29T02:17:52Z" + content=""" +The homebrew formula doesn't yet this fix, but you can get around the problem in the meantime by getting a newer SSH via homebrew: + +``` +brew install homebrew/dupes/openssh +``` + +You can then choose to keep that or get rid of it when the formula for git annex is later updated. +"""]] diff --git a/doc/forum/Git-annex_link_to_different_file_names.mdwn b/doc/forum/Git-annex_link_to_different_file_names.mdwn new file mode 100644 index 000000000..a7a7c2727 --- /dev/null +++ b/doc/forum/Git-annex_link_to_different_file_names.mdwn @@ -0,0 +1,41 @@ +This is a recreation of a stackexchange question, in case the community here is more knowledgeable. + +Link to stackexchange question : http://unix.stackexchange.com/questions/325753/git-annex-link-to-different-file-names + +Content : +"Maybe this is just a crazy use case that doesn't work, but I was wondering if there's a way to build a file's history from files with different file names. I'm exploring this idea because I'd like to have a git-annex system but I can't force my coworkers to adapt. + +Here's what I have in mind : + + Folder 1, managed by coworkers (On a shared disk) : + + drawing_shop_12_nov_2015.pdf + drawing_shop_13_nov_2015.pdf + drawing_asbuilt_14_nov_2015.pdf + drawing_asbuilt_rev1_15_nov_2015.pdf + +And + + Git-annex, managed by me : + + drawing.pdf + + (with a shop branch and a asbuilt branch) + +The git-annex's drawing.pdf would have an history like this : + + [shop] + | + Commit A "Initial shop drawing" + | + Commit B "Add corrections from Wizzbasket" + \ + | + [asbuilt] + Commit C "Reflect as built" + | + Commit D "Change dweezelbox block for simplicity" + +But somehow the "managed by coworkers" repo would be a direct mode repo with Commit A pointing to drawing_shop_12_nov_2015.pdf, Commit B to drawing_shop_13_nov_2015.pdf etc. + +Can this be done?" diff --git a/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn b/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn new file mode 100644 index 000000000..5e3b4d8b4 --- /dev/null +++ b/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn @@ -0,0 +1,27 @@ +I've somehow managed to get my indirect repository to symlink to literal content instead of object files. + +By this I mean literally the symlink is pointing at the contents of the file as the filename. + +So if I have a blah.txt file with this content: + +* First line +* second line + +And I ls -al to view the symlink pointer, it shows up as this: + +* blah.txt -> First line?second line + +It literally has the contents of the file as the destination filename. + +I've tried a couple things I could think of to re-symlink the files, but they don't seem to do anything as they think everything is fine: + +* git annex indirect //returns nothing +* git annex lock blah.txt //returns nothing +* git annex fix blah.txt //returns nothing +* git annex fsck //returns nothing + +I'm actually able to find several of these files hanging around by searching for all symlinks that don't point to something in the .git directory. + +Is there a way for me to replace the symlinks with correct symlinks to the objects in .git/annex? Can it even figure out which ones it was supposed to point to if the symlinks are messed up (are filenames -> content hashes stored anywhere else)? + +Else I might have to go do some manual rebasing and history editing to try to undo the bad commits manually. I've synced this repo to another direct repo so I'll need to figure out how to manually fix that repo too (using proxy). From what I can tell the annex/direct/master seems to be same as master and synced/master branches? Is there an [[internals]] page for direct branches besides [[direct_mode]] so I know what should be fixed where? diff --git a/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn b/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn new file mode 100644 index 000000000..dfc45cb4b --- /dev/null +++ b/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn @@ -0,0 +1,47 @@ +I want to use metadata views to sort files into top-level directories based on a tag, but then preserve the directory structure underneath that. I'm having trouble with this. + +Say I have an annex at `~/annex` with a structure like this: + + $ tree + . + ├── foo + │ └── bar + │ ├── one.txt + │ ├── three.txt + │ └── two.txt + └── waldo + └── fred + ├── a.txt + ├── b.txt + └── c.txt + +I tag some of the files with `blah`: + + $ git annex metadata -t blah foo/bar/* + +Now I want to change my view to only see those files with a certain tag, but I want to maintain their directory structure, ie I want to end up with something like this: + + $ tree + . + ├── blah + │ └── foo + │ └── bar + │ ├── one.txt + │ ├── three.txt + │ └── two.txt + +If I do `git annex view blah` I see the files `one.txt`, `two.txt` and `three.txt` but they are in the top level of `~/annex`. The `foo` and `bar` directories are not present. + +If I do `git annex view blah "/=*"` then the files I present under the `foo` directory, but the `bar` subdirectory is not there. + +It would also be fine if I could just hide the files that did not have the `blah` tag, so that I ended up with this: + + $ tree + . + ├── foo + │ └── bar + │ ├── one.txt + │ ├── three.txt + │ └── two.txt + +Is something like this possible? diff --git a/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn b/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn index 749a7937a..ca04e442c 100644 --- a/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn +++ b/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn @@ -1,20 +1,22 @@ I am attempting to set up automatic two-way synchronization between my laptop and a server via ssh by running assistant on both machines. I want to have both machines be non-bare and unlocked. -On the server: +On the rhel server: $ mkdir ~/annex - $ cd annex + $ cd ~/annex $ git init $ git annex init u --version=6 $ echo This is test file 1. >testfile1.txt $ git annex add testfile1.txt $ git annex sync + $ git remote add ml2 ssh://laptop/Users/username/annex $ git annex adjust --unlock $ git annex wanted . standard $ git annex group . client -On my laptop: +On my mac laptop: + $ cd ~/ $ git clone ssh://server/home/username/annex $ cd annex $ git annex init ml2 --version=6 @@ -23,8 +25,8 @@ On my laptop: $ git annex wanted . standard $ git annex group . client -Everything seems to work when I manually sync. When I run +Everything seems to work when I manually sync. But when I run $ git annex assistant -on both machines, however, I only get one-way automatic synchronization. Changes on the laptop are immediately propagated to the server. But changes on the server do not show up on the laptop until I manually sync. What am I doing wrong? +on both machines, I only get one-way automatic synchronization. Changes on the laptop are immediately propagated to the server. But changes on the server do not show up on the laptop until I manually sync. What am I doing wrong? diff --git a/doc/install.mdwn b/doc/install.mdwn index dccd9e52e..210493158 100644 --- a/doc/install.mdwn +++ b/doc/install.mdwn @@ -17,7 +17,7 @@ detailed instructions | quick install [[ScientificLinux5]] | [[openSUSE]] | `zypper in git-annex` [[Docker]] | -[[Windows]] | [download installer](https://downloads.kitenet.net/git-annex/windows/current/) **beta** +[[Windows]] | [download installer](https://downloads.kitenet.net/git-annex/windows/current/) and follow the [instructions here](http://git-annex.branchable.com/install/Windows/) **beta** """]] All the download links above use https for security. For added security, see diff --git a/doc/install/Windows.mdwn b/doc/install/Windows.mdwn index f079bf8cd..ff6a6adf4 100644 --- a/doc/install/Windows.mdwn +++ b/doc/install/Windows.mdwn @@ -2,8 +2,12 @@ git-annex now does Windows! * First, [install Git for Windows](http://git-scm.com/downloads) Important: **Get the 32 bit version not the 64 bit version.** - (Note that msysgit is no longer supported.) + (Note that msysgit is no longer supported.) If you installed the + 64 bit version of git, then parts of git-annex will still run, + however, some features, including tools like rsync, are not-functional. * Then, [install git-annex](https://downloads.kitenet.net/git-annex/windows/current/) + into the same location Git has been installed to. You must provide this path to the + git-annex installer. For instance, the path may be "C:\Users\John\AppData\Local\Programs\Git\" This port is now in reasonably good shape for command-line use of git-annex. The assistant and webapp are also usable. There are some known diff --git a/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment b/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment new file mode 100644 index 000000000..4d6f0cfc2 --- /dev/null +++ b/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="davidriod@e75b369a4b1cced29c14354bce7493c61f00b1c7" + nickname="davidriod" + avatar="http://cdn.libravatar.org/avatar/d6e327bd88b88802d6f0c20c83f682a2" + subject="Sharing rsync special remote between repository" + date="2016-11-24T19:23:42Z" + content=""" +I was wondering if it is possible to share a rsync special remote between repository which are not parented in any way. The use case would be that even if these repositories are not related at all they still may contains the same binary file. It would be useful to have a single rsync remote in order to reduce space usage. I think it could work as the object names are based on their checksum, but I wonder if anyone has already try that ? +"""]] diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment new file mode 100644 index 000000000..2c36962aa --- /dev/null +++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment @@ -0,0 +1,82 @@ +[[!comment format=mdwn + username="StephaneGourichon" + avatar="http://cdn.libravatar.org/avatar/8cea01af2c7a8bf529d0a3d918ed4abf" + subject="Walkthrough of a prudent retroactive annex." + date="2016-11-24T11:27:59Z" + content=""" +Been using the one-liner. Despite the warning, I'm not dead yet. + +There's much more to do than the one-liner. + +This post offers instructions. + +# First simple try: slow + +Was slow (estimated >600s for 189 commits). + +# In tmpfs: about 6 times faster + +I have cloned repository into /run/user/1000/rewrite-git, which is a tmpfs mount point. (Machine has plenty of RAM.) + +There I also did `git annex init`, git-annex found its state branches. + +On second try I also did + + git checkout -t remotes/origin/synced/master + +So that filter-branch would clean that, too. + +There, `filter-branch` operation finished in 90s first try, 149s second try. + +`.git/objects` wasn't smaller. + +# Practicing reduction on clone + +This produced no visible benefit: + +time git gc --aggressive +time git repack -a -d + +Even cloning and retrying on clone. Oh, but I should have done `git clone file:///path` as said on git-filter-branch man page's section titled \"CHECKLIST FOR SHRINKING A REPOSITORY\" + +This (as seen on https://rtyley.github.io/bfg-repo-cleaner/ ) was efficient: + + git reflog expire --expire=now --all && git gc --prune=now --aggressive + +`.git/objects` shrunk from 148M to 58M + +All this was on a clone of the repo in tmpfs. + +# Propagating cleaned up branches to origin + +This confirmed that filter-branch did not change last tree: + + git diff remotes/origin/master..master + git diff remotes/origin/synced/master synced/master + +This, expectedly, was refused: + + git push origin master + git push origin synced/master + +On origin, I checked out the hash of current master, then on tmpfs clone + + git push -f origin master + git push -f origin synced/master + +Looks good. + +I'm not doing the aggressive shrink now, because of the \"two orders of magnitude more caution than normal filter-branch\" recommended by arand. + +# Now what? Check if precious not broken + +I'm planning to do the same operation on the other repos, then : + +* if everything seems right, +* if `git annex sync` works between all those fellows +* etc, +* then I would perform the reflog expire, gc prune on some then all of them, etc. + +Joey, does this seem okay? Any comment? + +"""]] |