From 446659676aae40aaa1689f95540411af4b0e8c48 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 20 Feb 2017 14:49:03 -0400 Subject: comment --- ...omment_1_336e1c2a5c2a367cba0ad74896b3895b._comment | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_1_336e1c2a5c2a367cba0ad74896b3895b._comment diff --git a/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_1_336e1c2a5c2a367cba0ad74896b3895b._comment b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_1_336e1c2a5c2a367cba0ad74896b3895b._comment new file mode 100644 index 000000000..79a44d7c5 --- /dev/null +++ b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_1_336e1c2a5c2a367cba0ad74896b3895b._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2017-02-20T18:38:16Z" + content=""" +When you used embedcreds=yes, it *committed* the creds to the git-annex +branch of the git repository. For embedcreds=no to do anything useful, +it would need to remove that data from the git repository history. + +Removing data from a git repository tends to involve rewriting commits and +forced pushes to all remotes, it's not a simple process and not ameanable +to automation. It will be much easier, and more secure, to go into S3 +and generate new credentials, and revoke access to the old ones. + +What `git annex enableremote` with `embedcreds=no` does do is prevent +any new creds from being embedded into the repository. Otherwise, +`git annex enableremote` will update the embedded creds +with whatever new ones are set in the environment when you run it. +"""]] -- cgit v1.2.3