Hey Jim, There are definitely things I like about git-fat. I really liked how the configuration was a permanent fixture in the repo. But there were two things that were big down sides in my mind. The first was that you couldn't have multiple remotes if you wanted to. The second was that you had to sync all files, and not choose one by one. The second of these was the main reason I chose to favor git-annex over git-fat. Mostly because the input data repo for CESM is currently something on the order of tera to peta bytes. It seemed to me like we would require the capability of selecting the input files we wanted to transfer over. I would say, neither of them are that difficult to use. Git-fat is easier to use, and that was another thing I liked about it, but git-annex is not that complicated in addition. Doug On 06/11/2014 10:05 AM, Foucar, James G wrote:
Hi Doug,
Just looking at your google doc, it looks like the balance of pros/cons favors git-fat. An additional pro for git-fat is that the author is on our team.
I'm going to set up a test repo and see how git-fat works for me.
-Jim
On 6/11/14 8:09 AM, "Douglas Jacobsen" <[email protected]> wrote:
I went over this a long time ago in the google doc (https://docs.google.com/document/d/1EP9g8XQ0R25yyC9I-5fwOn-x4_Q60uO8wuHs2 S97RRQ/edit?usp=sharing) but each of the possible options for storing binary files has pros and cons.
The main pros for git-fat are that it stores the configuration file in the repo. The main cons for git-fat are that you can only have a single remote, and that you can't "sync" individual files, you either get all files or none of the files.
The main pros for git-annex are that you can have as many remotes as you want, and it's more flexible in that you can sync individual files to independent remotes. The main cons are it's a bit more complicated it use, and you can't store config files in the repo. So we'd either need a list of command people would use to configure git-annex, or we'd need a script to set it up for them.
Doug
On 06/11/2014 02:43 AM, Jed Brown wrote:
Douglas Jacobsen <[email protected]> writes:
So far, it seems like we're likely to require a minimum of 2-4 user accounts for each ACME person. 1) Github 2) "Hosted" input files (unless we don't mind them being world readable, in which case only people who will add new files or update files need access and accounts) Note that if those binary files are named by their sha1, for example, and directory listings are blocked, they can be world readable (because nobody will guess the file name). This is in fact one use case for git-fat: rsync pushes to a public http(s) directory and anyone that knows the sha1 can fetch over unauthenticated http(s).
ACME-SE mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/acme-se