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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
