git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [RFC PATCH 00/12] Sparse checkout
Date: Thu, 24 Jul 2008 02:35:45 -0700 (PDT)	[thread overview]
Message-ID: <m3tzefvd3q.fsf@localhost.localdomain> (raw)
In-Reply-To: <20080723145518.GA29035@laptop>

Nguyễn Thái Ngọc Duy <pclouds@gmail.com> 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

  parent reply	other threads:[~2008-07-24  9:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-23 14:55 [RFC PATCH 00/12] Sparse checkout Nguyễn Thái Ngọc Duy
2008-07-23 15:38 ` Nguyen Thai Ngoc Duy
2008-07-23 16:15 ` Johannes Schindelin
2008-07-23 16:21   ` Nguyen Thai Ngoc Duy
2008-07-23 16:55     ` Johannes Schindelin
2008-07-24  8:27       ` Nguyen Thai Ngoc Duy
2008-07-24 12:42         ` Johannes Schindelin
2008-07-24 13:29           ` Nguyen Thai Ngoc Duy
2008-07-24 13:44             ` Johannes Schindelin
2008-07-24 13:50               ` Nguyen Thai Ngoc Duy
2008-07-24 16:22                 ` Avery Pennarun
2008-07-24 16:38                   ` Johannes Schindelin
2008-07-24 18:59                   ` Nguyen Thai Ngoc Duy
2008-08-03 18:37       ` Jan Hudec
2008-08-03 20:48         ` Johannes Schindelin
2008-08-04 12:29         ` Nguyen Thai Ngoc Duy
2008-07-24  8:24 ` James Pickens
2008-07-24  9:00   ` Nguyen Thai Ngoc Duy
2008-07-24 17:59     ` James Pickens
2008-07-24 23:23       ` Nguyen Thai Ngoc Duy
2008-07-24 23:38         ` James Pickens
2008-07-24  9:35 ` Jakub Narebski [this message]
2008-07-24 10:58   ` Nguyen Thai Ngoc Duy
2008-07-24 20:01     ` Jakub Narebski
2008-07-24 23:21       ` Nguyen Thai Ngoc Duy
2008-07-25 14:53         ` Avery Pennarun
2008-07-25  0:07       ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3tzefvd3q.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).