Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:
> I have not looked at non-builtin commands yet, but I think it's not
> a big deal. We have several rounds before this series is good enough ;)
> So in short, sparse prefix will be stored in config, core.sparsecheckout.
> you have three new commands to enter/update/leave sparse checkout:
>
> git clone --path=prefix # clone with sparse checkout
> git checkout --path=prefix # limit/update checkout paths
> git checkout --full # stop sparse checkout
>
> Other operations should be normal. User attempts to do anything outside
> sparse checkout will get flagged. Git itself should not touch anything
> outside sparse checkout.
>
> One more thing. As files outside sparse checkout will not be checking
> out, .gitignore and .gitattributes from parent directories (outside
> sparse checkout) will be gone too. This may lead to surprise.
>
> Comments are welcome.
A note: my comments here reflects what I have remember from reading
comments in this thread; I have not examined the code, though.
First, I think that 'sparse checkout' is a better idea than former
'subtree (partial) checkout'; and I guess it could be easier to code.
Second, I think you can simply special case .git* files (.gitignore,
.gitattributes, .gitmodules), and always check them out for all
intermediate directories (unless configured otherwise, of course).
So for example if you have the following directory structure:
A/.gitignore
A/a
A/B1/.gitignore
A/B1/b
A/B2/.gitignore
A/B2/c
and you are checking out only subdirectory 'B1' (and all files in it;
if subdirectories are checked out recursively it depends on
configuration), and if for example there is .gitignore in every
directory, then checked out tree would look like this:
A/.gitignore
A/B1/.gitignore
A/B1/b
The ability to do this is one of advantages of 'sparse' checkout over
'subtree' checkout.
Third, about the place where to store information about which paths
are checked out, and which are not. There are three possible places
to store this information:
1. repository configuration, e.g. `core.sparsecheckout' variable
(multivalued?), like for `core.worktree'
2. some text file in $GIT_DIR, e.g. '.git/sparse', like for shallow
clone ("git clone --depth <depth>") it is grafts-like
$GIT_DIR/shallow (see Documentation/technical/shallow.txt).
3. in the index itseld ($GIT_DIR/index), as proposed by Johannes
Schindelin.
While I do think that some information about sparseness should be in
the index, for git to be able to commit from the index for example,
I don't think it is a good place as the only/main place to store
information about which paths are checked out; I think that because
IMVHO git commands should survive hosing (removing) index file.
Just my 2 eurocents.
--
Jakub Narebski
Poland
ShadeHawk on #git
--
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
