implemented upgrade of direct mode repo to v6

2 files changed, 14 insertions, 12 deletions

diff --git a/doc/todo/smudge.mdwn b/doc/todo/smudge.mdwn
index eeb34f135..6623a6d18 100644
--- a/doc/todo/smudge.mdwn
+++ b/doc/todo/smudge.mdwn
@@ -323,8 +323,12 @@ files to be unlocked, while the indirect upgrades don't touch the files.
 
 * Dropping a smudged file causes git status to show it as modified, 
   because the timestamp has changed. Getting a smudged file can also 
-  cause this. Avoid this by preserving timestamp of smudged files
-  when manipulating.
+  cause this. Upgrading a direct mode repo also leaves files in this state.
+  User can use `git add` to clear it up, but better to avoid this,
+  by updating stat info in the index.
+  (May need to use libgit2 to do this, cannot find
+  any plumbing except git-update-index, which is very inneficient for
+  smudged files.)
 * Reconcile staged changes into the associated files database, whenever
   the database is queried.
 * See if the cases where the Keys database is not used can be
@@ -335,8 +339,6 @@ files to be unlocked, while the indirect upgrades don't touch the files.
   (when not in direct mode).
   However, beware over-optimisation breaking the assistant or perhaps other
   long-lived processes.
-* Make v6 upgrade convert direct mode repo to repo with all unlocked
-  files.
 * Make automatic merge conflict resolution work for pointer files.
   - Should probably automatically handle merge conflicts between annex
     symlinks and pointer files too. Maybe by always resulting in a pointer
diff --git a/doc/upgrades.mdwn b/doc/upgrades.mdwn
index d69941cb1..27f22e16e 100644
--- a/doc/upgrades.mdwn
+++ b/doc/upgrades.mdwn
@@ -48,6 +48,12 @@ The upgrade events, so far:
 The upgrade from v5 to v6 is handled manually. Run `git-annex upgrade`
 perform the upgrade.
 
+Warning: All places that a direct mode repository is cloned to should be 
+running git-annex version 6.x before you upgrade the repository.
+This is necessary because the contents of the repository are changed
+in the upgrade, and the old version of git-annex won't be able to
+access files after the repo is upgraded.
+
 This upgrade does away with the direct mode/indirect mode distinction.
 A v6 git-annex repository can have some files locked and other files
 unlocked, and all git and git-annex commands can be used on both locked and
@@ -65,19 +71,13 @@ The behavior of some commands changes in an upgraded repository:
 * `git annex unlock` and `git annex lock` change how the pointer to 
   the annexed content is stored in git.
 
-All places that a direct mode repository is cloned to should be 
-running git-annex version 6.x before you upgrade the repository.
-This is necessary because the contents of the repository are changed
-in the upgrade, and the old version of git-annex won't be able to
-access files after the repo is upgraded.
-
 If a repository is only used in indirect mode, you can use git-annex
 v5 and v6 in different clones of the same indirect mode repository without
 problems.
 
 On upgrade, all files in a direct mode repository will be converted to
-unlocked files. The upgrade will need to stage changes to all files in
-the git repository.
+unlocked files. The upgrade will stage changes to all annexed files in
+the git repository, which you can then commit.
 
 If a repository has some clones using direct mode and some using indirect
 mode, all the files will end up unlocked in all clones after the upgrade.