git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "Nguyen Thai Ngoc 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 22:01:23 +0200	[thread overview]
Message-ID: <200807242201.23991.jnareb@gmail.com> (raw)
In-Reply-To: <fcaeb9bf0807240358l6584c063u85179196bd6db30a@mail.gmail.com>

On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> On 7/24/08, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> >  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.
> 
> Or teach git to use index version of those files. Or collect all those
> files, combine them and put the result to .git/info/exclude (and
> similar places). Anyway well organized repos won't have this problem.
> 
> Checking some files out as read-only (like this case) may be
> interesting. Though I do not how much complicated it can be.

I think teaching git to use index version of .git* files (.gitignore,
.gitattributes, .gitmodules) would be much more work than adding
default rule that .git* files in leading directories are by default
checked out, just like leading directories are checked out.  This
would limit modifying git code, I think, and chances for errors.

Having "leading" directories and files read-only would be a good idea,
I think.

I don't understand the sentence "well organized repos won't have this
problem". I think well organized repos _would_ have this problem,
because of maintained and distributed top-level .gitignore and
.gitattributes.

P.S. I hope that 'sparse checkout' feature would be ready for 1.7.0
-- 
Jakub Narebski
Poland

  reply	other threads:[~2008-07-24 20:02 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
2008-07-24 10:58   ` Nguyen Thai Ngoc Duy
2008-07-24 20:01     ` Jakub Narebski [this message]
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=200807242201.23991.jnareb@gmail.com \
    --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).