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: Mon, 12 Feb 2007 16:29:39 +0200 [thread overview]
Message-ID: <45D079D3.2020500@dawes.za.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0702121508360.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Feb 2007, Rogan Dawes wrote:
>
>> Johannes Schindelin wrote:
>>> (my favourite:)
>>> - use git-split to create a new branch, which only contains doc/. Do work
>>> only on that branch, and merge into mainline from time to time.
>> Your third option sounds quite clever, apart from the problem of attributing a
>> commit and a commit message to someone, when the actual commit doesn't match
>> what they actually did :-(
>
> This problem is not related to subprojects at all. If the commit message
> does not match the patch, you are always fscked.
Well, I was thinking about the fact that the files originally checked in
will not match the files "checked in" in the rewritten commit.
>> As well as wondering what happens when they check out a few more files. Do we
>> rewrite those commits as well? What happens if the user has made some commits
>> already? What happens if they have already sent those upstream? etc.
>
> I think you misunderstood. My favourite option would make docs a
> _separate_ project, with its own history. It just happens to be pulled
> from time to time, just like git-gui, gitk and git-fast-import in git.git.
I see. However, that does not allow for the random single-file checkout
scenario I sketched out. Which may or may not be common/desirable, but
it is an extreme case of the partial checkout, without fixed delineation.
>> I think the best solution is ultimately to make git able to cope with
>> certain missing objects.
>
> Hmm. I am not convinced. On nice thing about git is its level of
> integrity. Which means that no random objects are missing.
Good point. :-(
>> I started writing this in response to another message, but it will do fine
>> here, too:
>>
>> The description I give here will likely horrify people in terms of
>> communications inefficiency, but I'm sure that can be improved.
>>
>> [goes on... and describes the lazy clone!]
>
> AFAICT this really is the lazy clone. And it was already determined that
> it is all to easy to pull in all commit objects by accident. Which boils
> down to a substantial chunk of the repository.
>
Not so much a lazy clone as a partial clone. It is only in the "clone",
"fetch" or "checkout" code paths that new objects will be retrieved from
the source repo. Things like "git log"/"git show" would not do so, and
would be required to handle missing objects gracefully.
> But if you want to play with it: by all means, go ahead. It might just be
> that you overcome the fundamental difficulties, and we get something nice
> out of it.
>
> Ciao,
> Dscho
>
Maybe ;-) We'll see if I get any time for it.
Rogan
prev parent reply other threads:[~2007-02-12 14:31 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
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 [this message]
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=45D079D3.2020500@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).