[RFC PATCH 0/9] Narrow/Sparse checkout round 3: "easy mode"

The implementation with insights from Junio turns out smaller and better (and I was thinking about applying it for huge maildir).

So there is a bit of changes since the last round. This time I follow "assume unchanged" code path and relax the rules a bit. There are issues I will mention later.

From user POV, we can now checkout a single file or a subdirectory (checking out subdirectory non-recursively is possible too). You may start with a narrow clone like:

git clone --path="Documentation/*" git.git

or start from a full checkout and narrow it (very much like the last round):

git checkout --path="Documentation/*"

However narrow spec is now using wildcards, not prefix, so you can checkout a single file, or just header files, etc.

git checkout --add-path|--remove-path has been aded to update narrow areas. But you don't have to use those. Narrow areas will be widened as needed when you do something outside of it (e.g "git checkout foo" or "git add foo"...)

Another difference from the last round is "narrow rules" will not be preserved when switching branches. When you switch branch with no option, you will get full checkout. You may want to use --path|--add-path|--remove-path when switching branches to have narrow checkout again.

Now back to technical POV. I did not reuse CE_VALID (assume unchanged) bit because it has been used for core.ignorestat. So I took another bit, which seems to be the last on-disk bit in ce_flags.

I call this mode "easy mode" because most of constraints have been eliminated. Now your "narrow rules" are like "I don't like those files, remove them if they are not needed". If some operations need those files on workdir again, they will be checked out. Those may include:

 - "git checkout foo" or "git apply"
 - git add foo (even if foo is marked no-checkout)
 - conflict files after merge
 - new files after merge

"Strict mode" may be added later but then it must clearly define which operation is allowed to checkout files. There's a problem with strict mode if it wants to limit checking out new files after merge. Because we don't save "narrow rules" anymore (we applied the rules immediately in checkout/clone stage, then update narrow areas over time), we will not know how to deal with new files. Adding [--path|--add-path|--remove-path] to git merge commands, and apply "narrow rules" again, looks too cumbersome to me. Comments?

Last bit. "Narrow rules" for --path|--add-path|--remove-path is currently wildcards separated by colons. While it does the job, it does not allow to checkout easily a subdirectory non-recusively. I was thinking about '*' as "match everything except slashes" and '**' as "match everything even slashes". Any ideas?

Oh.. and "git grep" may not work correctly (or "as expected") with narrow checkout. Haven't checked it yet.

Nguyễn Thái Ngọc Duy (9):
  Introduce CE_NO_CHECKOUT bit
  update-index: add --checkout/--no-checkout options to update
    CE_NO_CHECKOUT bit
  ls-files: add --checkout option to show checked out files
  Prevent diff machinery from examining worktree outside narrow
    checkout
  Clear CE_NO_CHECKOUT on checked out entries.
  Add support for narrow checkout in unpack_trees()
  ls-files: add --narrow-match=spec option to test narrow matching
  clone: support narrow checkout with --path option
  checkout: add new options to support narrow checkout

 builtin-checkout.c     |   41 ++++++++++++++++++
 builtin-clone.c        |   13 ++++++
 builtin-ls-files.c     |   23 +++++++++--
 builtin-update-index.c |   40 +++++++++++-------
 cache.h                |   11 +++++
 diff-lib.c             |    5 +-
 diff.c                 |    4 +-
 entry.c                |    1 +
 read-cache.c           |    6 +-
 unpack-trees.c         |  106 ++++++++++++++++++++++++++++++++++++++++++++++++
 unpack-trees.h         |    4 ++
 11 files changed, 229 insertions(+), 25 deletions(-)