git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Rogan Dawes <lists@dawes.za.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Christoph Duelli <duelli@melosgmbh.de>, git@vger.kernel.org
Subject: Re: restriction of pulls
Date: Fri, 09 Feb 2007 17:32:46 +0200	[thread overview]
Message-ID: <45CC941E.9030808@dawes.za.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0702091554160.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 9 Feb 2007, Christoph Duelli wrote:
> 
>> Is it possible to restrict a chechout, clone or a later pull to some 
>> subdirectory of a repository?
> 
> No. In git, a revision really is a revision, and not a group of file 
> revisions.
> 
> Ciao,
> Dscho
> 

I thought about how this might be implemented, although I'm not entirely 
sure how efficient this will be.

One obstacle to implementing partial checkouts is that one does not know 
which objects have changed or been deleted. One way of addressing this 
is to keep a record of the hashes of all the objects that were NOT 
checked out. (If one does not check out part of a directory, simply 
store the hash of the top level, and you do not need to store the child 
hashes.) This record would be a kind of "negative index".

When deciding what to check in, or which files are modified, one would 
check the "negative index" first to see if an entry exists. If not, only 
then would you check the filesystem to see if modification times have 
changed. With the "negative index", and the files in the file system, 
one would be able to construct new commits, without any problem.

It would also require an updated transfer protocol, which would allow 
the client to specify a tag/commit, then walk the tree that it points to 
to find the portion that the client is looking for, then pull only those 
objects (and possibly their history). This is likely to be VERY 
inefficient in terms of round trips, at least initially.

This might be able to benefit from the shallow checkout support that was 
recently implemented.

Comments?

Rogan

  reply	other threads:[~2007-02-09 15:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-09 10:49 restriction of pulls Christoph Duelli
2007-02-09 11:19 ` Jakub Narebski
2007-02-09 14:54 ` Johannes Schindelin
2007-02-09 15:32   ` Rogan Dawes [this message]
2007-02-09 16:19     ` Andy Parkins
2007-02-09 16:36       ` Rogan Dawes
2007-02-09 16:45         ` Andy Parkins
2007-02-09 17:32           ` Rogan Dawes
2007-02-10  9:59             ` Andy Parkins
2007-02-10 14:50     ` Johannes Schindelin
2007-02-12 13:58       ` Rogan Dawes
2007-02-12 14:13         ` Johannes Schindelin
2007-02-12 14:29           ` Rogan Dawes

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=45CC941E.9030808@dawes.za.net \
    --to=lists@dawes.za.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=duelli@melosgmbh.de \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).