git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tony.luck@intel.com
To: Ehud Shabtai <eshabtai.lkml@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: trying to figure out this git thing - some questions
Date: Thu, 14 Apr 2005 16:52:13 -0700	[thread overview]
Message-ID: <200504142352.j3ENqDB06021@unix-os.sc.intel.com> (raw)
In-Reply-To: <68b6a2bc05041412025f1cb7c9@mail.gmail.com>

>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

      reply	other threads:[~2005-04-14 23:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-14 19:02 trying to figure out this git thing - some questions Ehud Shabtai
2005-04-14 23:52 ` tony.luck [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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200504142352.j3ENqDB06021@unix-os.sc.intel.com \
    --to=tony.luck@intel.com \
    --cc=eshabtai.lkml@gmail.com \
    --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.
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).