git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Jaeger <christian@jaeger.mine.nu>
To: Andreas Ericsson <ae@op5.se>
Cc: Garry Dolley <gdolley@arpnetworks.com>,
	Richard Hartmann <richih.mailinglist@gmail.com>,
	git@vger.kernel.org
Subject: Re: Feedback outside of the user survey
Date: Mon, 20 Oct 2008 18:57:31 +0200	[thread overview]
Message-ID: <48FCB87B.1080207@jaeger.mine.nu> (raw)
In-Reply-To: <48FCADA0.4020008@op5.se>

Andreas Ericsson wrote:
> Christian Jaeger wrote:
>> Hm, not sure whether you mean to rescue the situation with rewritten 
>> commits here -- but hell no, I certainly don't mean to have different 
>> commit objects for different clones/checkouts.
>>
>
> Then you'll be transferring all objects over the wire anyway

Why? Again, care to differentiate between technical feasibility and 
current implementation.

I did make a list of cases in my pre-previous email which tried to go 
through the implications.

>>> What you'd end up with wouldn't be a git repository at all anymore. It
>>> would be a "stump", as it'd be missing large parts of the tree 
>>> entirely.
>>
>> That was my point, yes.
>>
>
> That's partially implemented, I think (google for Nguy (or something, I'm
> not very god with asian names),

That's not enough information for me to find what you've had in mind. 
"stump Nguy site:marc.info" doesn't yield a result with Google.

> but your original suggestion said to save
> on transferring objects from one machine to another, 

Yes

> which will play poorly
> with git's object database

Why, if we seem to already have agreed that the object database would be 
a "stump"? It may play poorly with the current implementation of the 
database maintainance code, but I don't see why it would play poorly 
with the database's data structure design.

> and which you're now arguing against.

I don't get this part of the sentence.

I did (3 mails ago) say, "(one) could additionally look into 
implementing a kind of shallow cloning". When you said that the kind of 
repository I'm "arguing" for would be a "stump", that sounded exactly 
what I've meant, in the same sense that a shallow clone creates a 
repository that is missing part of the tree (or maybe DAG is a better 
term). So I said "That was my point, yes", maybe I should have said 
"That's what I've meant when I was saying a 'kind of shallow cloning'." 
Ok? I might miss some fine points in the english language as I'm not a 
native speaker.

>
> Please make up your mind.

About what?

Do you mean whether I want to implement the idea? Then no, I don't see 
myself contributing any code for this. I certainly don't have a use case 
personally where it would pay off. My motivation to contributing to this 
thread was to point out that there is, afaik, nothing inherent in the 
Git design (at least the database) which would absolutely prevent one 
from implementing subdirectory checkouts (including even saving on 
bandwith by doing some kind of shallow / stump / lazy cloning).

Christian.

  reply	other threads:[~2008-10-20 16:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-16 10:19 Feedback outside of the user survey Richard Hartmann
2008-10-16 10:28 ` Jeff King
2008-10-16 11:08   ` Richard Hartmann
2008-10-16 11:56 ` Garry Dolley
2008-10-16 13:18   ` Richard Hartmann
2008-10-16 20:32     ` Christian Jaeger
2008-10-18 13:49       ` Garry Dolley
2008-10-18 14:01         ` Christian Jaeger
2008-10-20  9:57           ` Andreas Ericsson
2008-10-20 14:43             ` Christian Jaeger
2008-10-20 15:02               ` Andreas Ericsson
2008-10-20 15:20                 ` Christian Jaeger
2008-10-20 16:11                   ` Andreas Ericsson
2008-10-20 16:57                     ` Christian Jaeger [this message]
2008-10-20 17:30                       ` Christian Jaeger
2008-10-20 22:41                       ` Junio C Hamano
2008-10-21  7:24                         ` Christian Jaeger

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=48FCB87B.1080207@jaeger.mine.nu \
    --to=christian@jaeger.mine.nu \
    --cc=ae@op5.se \
    --cc=gdolley@arpnetworks.com \
    --cc=git@vger.kernel.org \
    --cc=richih.mailinglist@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).