Linus Torvalds [off-list ref] writes:
On Sat, 9 Jul 2005, Eric W. Biederman wrote:
quoted
The current intelligent fetch currently has a problem that it cannot
be used to bootstrap a repository. If you don't have an ancestor
of what you are fetching you can't fetch it.
Sure you can.
See the current "git clone". It's actually quite good, it's a pleasure to
use now that it gives updates on how much it has done.
Just do
git clone src dest
Sorry, somehow I just missed that, and then I noticed just a little
before you sent out your email.
I'm having the worst time putting together a mental model of how git
works, and the documentation is spotty enough that it hasn't been
helpful. So I am wading through the code. It seems every time I turn
a corner there is another rough spot.
I guess I was expecting to pull from one tree into another unrelated
tree. Getting a tree with two heads and then be able to merge them
together.
A couple of questions.
1) Does git-clone-script when packed copy the entire repository
or just take a couple of slices of the tree where you have
references?
2) Is there a way for a pack to create deltas against objects
that are not in the tree? For a dumb repository making incremental
changes this is ideal.
Eric
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
I guess I was expecting to pull from one tree into another unrelated
tree. Getting a tree with two heads and then be able to merge them
together.
You can do it, but you have to do it by hand. It's a valid operation, but
it's not an operation I want people to do by mistake, so it's not
something the trivial helper scripts help with.
The way to do it by hand is to just use something stupid that doesn't
understand what it's doing anyway, and just copy the files over. "cp -a"
or "rsync" works fine. Then just do "git resolve" by hand. It's not very
hard at all, but it's definitely something that should be a special case.
A couple of questions.
1) Does git-clone-script when packed copy the entire repository
or just take a couple of slices of the tree where you have
references?
It only gets the objects needed for the references, nothing more.
So if you only get one branch, it will leave the objects that are specific
to other branches alone.
2) Is there a way for a pack to create deltas against objects
that are not in the tree? For a dumb repository making incremental
changes this is ideal.
A pack can only have deltas against objects in that pack. It caan't even
have deltas to other objects in the same tree, it literally is only
_within_ a pack. This is so that each pack is totally independent: you can
always unpack (and verify) the objects in a pack _without_ having anything
else (of course, the end result is often not a full project, and you won't
have any references, but at least the _objects_ are valid).
I don't want to have deltas to outside the pack, because while it's
obviously very nice from a size packing standpoint, it's totally horrid
from an infrastructure standpoint. It would make it possible to have
circular dependencies (ie deltas against each other) that could only be
resolved by having a third pack (or the unpacked object).
It would also means that you may have to have two packs mapped at the same
time to unpack them, which was very much against what I was aiming for: I
think that in the long run, for truly huge projects, you'd want to have a
history of packs, each maybe a gigabyte in size, and you may be in the
situation that you simply cannot have two packs mapped at the same time
because you don't have enough virtual memory for it.
So then inter-pack deltas would mean that you'd have to have "partial pack
mapping" etc horrid special case logic. Right now, because a pack is
always self-sufficient, you know that in order to unpack an object, if you
find it in the index file, you will be able to unpack it by just mapping
that pack and going off..
So the rule is: don't pack too often. The unpacked objects are actually
working really really well as long as you don't have tens of thousands of
them. Having a few hundred (or even a few thousand) unpacked objects is
not a problem at all. Then you do a "git repack" when it starts getting
uncomfortable, and you you continue.
Linus
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
I'm having the worst time putting together a mental model of how git
works, and the documentation is spotty enough that it hasn't been
helpful. So I am wading through the code. It seems every time I turn
a corner there is another rough spot.
Btw, I know I'm bad at writing docs, but what I _do_ enjoy doing is
answering reasonably specific technical questions, and maybe somebody else
can write docs by taking advantage of me that way.
I tried to write the tutorial in a way that it also tries to explain how
git works (not just a "do this", but a "you update the index file and then
write the result out as a tree object"), but it obviously covers a fairly
limited part of what git actually can do, and at the same time it doesn't
go into a lot of detail.
And part of that is not just my inability to write documentation, it's
also that I just have the wrong "view" of the project, ie I probably just
take a lot of things for granted and consider them obvious, even though
they aren't, and then I probably occasionally explain things that aren't
worth explaining, because either they _are_ obvious, or people just don't
care and they are irrelevant.
I'd love to see somebody write up more of a "this is how you use git" kind
of tutorial, _and_ on the other hand more of a low-level explanation of
the notion of an object store where objects refer to each other by their
SHA1 names, and how that is represented in the filesystem and/or in packs.
Something with a few pictures would be great (ie screenshots of gitk, but
also something that tries to just visually show hot tags point to commits
that point to parents and trees, and trees pointing to other trees and
then blobs).
All things that I'm a complete idiot at, but that would help users
visualize what the heck git is actually _doing_, so that they don't just
parrot some magic command line that they don't understand, but can
actually reason about what they are doing.
I think a lot of people do understand this, but yes, the docs are kind of
lacking.
Linus