trying to figure out this git thing - some questions

trying to figure out this git thing - some questions

[Ehud Shabtai]

I'm trying to understand how it works and I'll appreciate if someone could help.

1. git uses object abstraction for the different types and so
everything is in one directory (objects). From what I've seen in the
implementation, the different kind of objects are not of the same type
(there aren't any operations which work on two different types) and
thus in each step when an object is used its type is verified.
What's the benefit of having them all in the same tree? An alternative
would be to separate the different object types into different
directories which trivially allows getting a list of all commits, or
trees or blobs.

2. A commit can have more than one parent. Can anyone draw an example
of such a case? When do we get a commit graph which is not linear?

3. How does git handle binary files? I guess it doesn't really care if
it's binary or text, but how would the diff and merge scripts handle
them?

Re: trying to figure out this git thing - some questions

[tony.luck]

>I'm trying to understand how it works and I'll appreciate if someone could help.

>1. git uses object abstraction for the different types and so
>everything is in one directory (objects). From what I've seen in the
>implementation, the different kind of objects are not of the same type
>(there aren't any operations which work on two different types) and
>thus in each step when an object is used its type is verified.
>What's the benefit of having them all in the same tree? An alternative
>would be to separate the different object types into different
>directories which trivially allows getting a list of all commits, or
>trees or blobs.

If all the commits were in ".git/objects/commits/xx/xxxxx", etc. then every
time git opened a file the kernel would have one extra level of directory
to walk to get to the file ... so opens would be fractionally slower. There
is no normal-use upside to this overhead.  While it would be easier to find
all the blobs if they were kept separate from the trees and commits, there
isn't any time that we'd ever want to scan through just the blobs.  Git never
goes searching through a directory opening files to see what they are
(exception: fsck-cache does scan all objects).

>2. A commit can have more than one parent. Can anyone draw an example
>of such a case? When do we get a commit graph which is not linear?

When a merge happens.  E.g. I take a snapshot of Linus' tree when a file
is at version 1.2.  We both make a couple of changes before I ask him to
pull from my tree:

	1.1 -> 1.2 -> 1.3 -> 1.4 -> 1.5
                \                  /
                1.2.1 -> 1.2.2 ---/

The changeset to create 1.5 has two parents ... the changeset that Linus made
to create 1.4, and the changeset that I made to create 1.2.2

>3. How does git handle binary files? I guess it doesn't really care if
>it's binary or text, but how would the diff and merge scripts handle
>them?

Yes, git doesn't care.  Diff is somewhat smart about noticing that its
input files aren't text:

	$ diff /bin/cat /bin/ls
	Binary files /bin/cat and /bin/ls differ

But in general this will be an issue for the SCM layer if there are binary
files checked into the tree.

-Tony