define a failing test for switching to branches that leaves a dependency unlinked, looking towards addressing this as a feature in the near future.

currently, mdm leaves the working tree alone.  it's a situation where the config defining the desired state is versioned, and there's a tool dragging the world along behind it: absense of config is different than config for removal.  Other dependency managers have similar issues; concretely, I tried ivy once and was surprised to discover my working tree stayed rather un-gc'd (though of course usually that goes somewhere under your homedir; it's better if you don't make eye contact, right?); and I've seen blogs describing the issue for devops tools as well; basically I don't feel alone in this issue.

but, i think we might be able to do something clever with dropping an owned-by-mdm flag in the git data dir of dependency submodules.  that would give us enough information to know what we can safely remove (vs what's a submodule we don't own, or what's another git repo just hanging out).  solution still needed for how to actually detect the submodule repos once on a branch that's missing the gitlink, though -- the current SubmoduleWalk code path won't cut it for that.
create a new test fixture repo that contains a series of commits.
sanity test against how submodule merging usually works in plain git.
Merge branch 'doc'
some research on a possible flow for temporarily replacing a linked dependency with a pointer elesewhere.

this is more out of interest than because it's necessarily a good idea.  i might still suggest that `git status` *should always* tell you if you have uncomitted changes, and that a dev workflow that lets you silently diverge from what's published in commits is a Generally Bad Idea.
admit to having an eclipse config.

i hate admitting information about an ide leak into a project's source, but untracked files are irritating.
comment for possible future efficiency improvement, not sure what edge cases i might need test coverage for yet though
docs: give a concrete example of how to inspect a release.  also emphasize how nuke-and-pave is an excellent solution to cleaning up in case of a slip.
starting in on a way to perform cleanup of unlinked dependencies after e.g. a branch switch.  this would implement the feature that SwitchingToBranchWithoutDeps is already testing for (I should have put that test on a branch, because it's currently failing on master).
attempting to add a dependency under a gitignore'd path is currently broken; test to demonstrate.  fix if i was using the git cli is easy; but an equivalent option isn't available from jgit's porcelain yet.
satisfy some curosity: no, nested commands cannot share a dircache lock reentrantly.

also, discovered that LockFailedException is yet another completely egregious abuse of IOException.  a lock failed is cause for retry, or a user level warning about concurrent modification... it's not cause pretending like the disk is falling apart underneath you.
suppose for a moment that forking the entire body of the AddCommand seemed reasonable.
then suppose you rewrote it to ignore a whole bunch of stuff you didn't want, and it worked flawlessly.  ta da: GitignoreInteractionsTest now passes.
import cleanup
wip on building a new walk utility to help discover dangling git repos in a working tree that aren't referenced by gitlinks in the dircache.  also had to touch build config, since this has classes that are only referenced from tests so far.
Merge branch 'fix-linking-deps-under-gitignore-paths'
working SubrepoWalk.
`mdm update` has now learned to clean up any directories containing dependencies that are unlinked on your current branch.  SwitchingToBranchWithoutDeps.should_delete_unlinked_deps_on_update passes.
ooh, we should be careful about disposing of any repo that contains uncommitted changes, even if it is mdm-managed.  everything else remains in the data dir under the parent's .git dir, but if the work tree is nuked, uncommitted changes have no where to go.
remove debug printfs