From ba233606d25ce9f1207ea74c5cb96d3931671d8b Mon Sep 17 00:00:00 2001 From: "http://joey.kitenet.net/" Date: Sat, 7 Jan 2012 17:15:31 +0000 Subject: Added a comment --- .../comment_1_dee73a7ea3e1a5154601adb59782831f._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment diff --git a/doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment b/doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment new file mode 100644 index 000000000..c37561665 --- /dev/null +++ b/doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="comment 1" + date="2012-01-07T17:15:31Z" + content=""" +Well, lock could check for modifications and require --force to lose them. But the check could be expensive for large files. + +But `git annex lock` is just a convenient way to run `git checkout`. And running `git checkout` or `git reset --hard` will lose your uncommitted file the same way obviously. + +Perhaps the best fix would be to get rid of `lock` entirely, and let the user use the underlying git commands same as they would to drop modifications to other files. It would then also make sense to remove `unlock`, leaving only `edit`. +"""]] -- cgit v1.2.3