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(-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
