From 9f1e3eb12f9d6c2d4039390bb88dca28ceae5931 Mon Sep 17 00:00:00 2001 From: Farhan Date: Tue, 14 Jun 2016 06:40:54 +0000 Subject: [PATCH 1/4] --- ...allows_user_to_attempt_deleting_an_unsynced_repo.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn diff --git a/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn b/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn new file mode 100644 index 0000000000..61fb707dbb --- /dev/null +++ b/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn @@ -0,0 +1,9 @@ +I made an attempt to tackle the following bug: + +[webapp should notice when remote deletion cannot complete due to not syncing](https://git-annex.branchable.com/bugs/webapp_should_notice_when_remote_deletion_cannot_complete_due_to_not_syncing/) + +My changes are in the following git repository + +[https://github.com/kathawala/git-annex.git](https://github.com/kathawala/git-annex.git) + +And the specific commit which fixes the bug is in a branch titled "unsync-nodelete". I have tested the change, it greys out and disables the "Delete" option in the "Actions" dropdown menu of the webapp for any repo in the "Repolist" view which has its syncing disabled. There is also some hover text which explains why the option is greyed out. Hope it is satisfactory! Thanks for your great work!! From 079d05eb17ff2f0f30b4097c53daa8f853d93f08 Mon Sep 17 00:00:00 2001 From: jgoerzen Date: Tue, 14 Jun 2016 22:08:44 +0000 Subject: [PATCH 2/4] Added a comment: Experienced this --- ...nt_2_35f59adc30fe743221f29bbfecff639b._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/bugs/Empty_folders_don__39__t_get_remove/comment_2_35f59adc30fe743221f29bbfecff639b._comment diff --git a/doc/bugs/Empty_folders_don__39__t_get_remove/comment_2_35f59adc30fe743221f29bbfecff639b._comment b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_2_35f59adc30fe743221f29bbfecff639b._comment new file mode 100644 index 0000000000..e471d33664 --- /dev/null +++ b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_2_35f59adc30fe743221f29bbfecff639b._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="jgoerzen" + subject="Experienced this" + date="2016-06-14T22:08:43Z" + content=""" +Hi, + +I experienced this just now. Have a git-annex assistant repo set up (so using direct mode). + +On one machine, I mv'd entire directories out of the git-annex repo. + +The other machine saw the files deleted, but the directories remained. + +On the machine on which I mv'd directories out, git-annex actually re-created some of them with symlinks to now-nonexistant hashes! I have no idea why it did that. +"""]] From b245e8aeb0af43e7e9eac77245a435b93605d7b7 Mon Sep 17 00:00:00 2001 From: jgoerzen Date: Tue, 14 Jun 2016 22:35:59 +0000 Subject: [PATCH 3/4] Added a comment: Version --- .../comment_3_ccc703f8667805ce2886719c57e76ef8._comment | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/bugs/Empty_folders_don__39__t_get_remove/comment_3_ccc703f8667805ce2886719c57e76ef8._comment diff --git a/doc/bugs/Empty_folders_don__39__t_get_remove/comment_3_ccc703f8667805ce2886719c57e76ef8._comment b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_3_ccc703f8667805ce2886719c57e76ef8._comment new file mode 100644 index 0000000000..93bb20f255 --- /dev/null +++ b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_3_ccc703f8667805ce2886719c57e76ef8._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="jgoerzen" + subject="Version" + date="2016-06-14T22:35:59Z" + content=""" +Forgot to add: 5.20151208 +"""]] From a950a978af8d694310643553d5fb5d576f48f57a Mon Sep 17 00:00:00 2001 From: hpd Date: Wed, 15 Jun 2016 09:54:38 +0000 Subject: [PATCH 4/4] --- ...committed_changes_staged_in_the_index.mdwn | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn diff --git a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn new file mode 100644 index 0000000000..ffad58ec84 --- /dev/null +++ b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn @@ -0,0 +1,37 @@ +### Please describe the problem. + +I understand that `git annex unannex` is essentially there for undoing an accidential `git annex add`. Unfortunately it doesn't do that. + +If I have uncommited changes, which is the case after a `git annex add`, it tells me: + + git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit + CallStack (from HasCallStack): + error, called at ./Command/Unannex.hs:48:19 in main:Command.Unannex + +But I would expect it to `git reset` the file and then replace the symlink by the actual file content. + +### What steps will reproduce the problem? + + > git init + Initialized empty Git repository in /somewhere/.git + > git annex init + init ok + (recording state in git...) + > touch foo + > git annex add foo + add foo ok + (recording state in git...) + > git annex unannex foo + git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit + CallStack (from HasCallStack): + error, called at ./Command/Unannex.hs:48:19 in main:Command.Unannex + +### What version of git-annex are you using? On what operating system? + +git-annex version: 6.20160527-gf21a425 + +Installed from the Arch Linux repository. + +### 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) + +Sure, I'm using it for photos, music and videos