Re: Importing from tarballs; add, rm, update-index?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 13, 2007, 11:17 UTC
Message-ID: <Pine.LNX.4.63.0701131204511.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <20070113093322.GA4825@xp.machine.xx>

Hi,

On Sat, 13 Jan 2007, Peter Baumann wrote:

Show 18 quoted lines

> On Fri, Jan 12, 2007 at 04:48:09PM -0800, Junio C Hamano wrote:
> > Peter Baumann <waste.manager@gmx.de> writes:
> > 
> > > ? What does it mean to "add" something to a project? It has 
> > > _nothing_ to do ? with "filenames". Yeah, the filename obviously 
> > > exists, but it's not ? something that exists on its own. You add the 
> > > ONLY thing that git tracks. ? ? You add CONTENT. ? ? When you do 
> > > "git add file.c" you aren't adding a filename to the list of ? files 
> > > that git knows about. Not even CLOSE. No. You are really adding ? 
> > > _content_ to the project you are tracking.
> > 
> > Read this again, please.  Ponder it if you may.
> > 
> 
> Yes. I am adding content. And not a file. But at least to me, it makes a
> *BIG* difference if I'm adding totally new content (reserving one more
> bucket where to place to content) or just replacing the content *in* one
> of those already reserved buckets.

Bzzzzt! Nope. "Reserved buckets" as you use it is nothing else than a file.

> And that has nothing to do with files (or at least the silly me can't 
> grok it).

Content: a byte stream with a label (so you can find it again). Of 
_course_ you don't want the byte stream vanish in a big black hole, so you 
_have_ to name it.

But git-add actually does two things: it adds a (completely new) object, which just holds the byte stream, being named by its content (the hash).

But when committing, the _existing_ tree object is "updated", by writing a _new_ tree object. So, it is not an "updating" in the sense of "editing", rather "updating" as in copy-on-write.

So no, there are no "reserved buckets". You are very much _adding_ new information.

Another way to look at it: in git, you never "take away" anything. You only add things. Even if you remove a file from your working tree, and want to commit the change, it means that you _add_ information: The information that this file is no longer in the current revision. But the commit references the old revision (indeed, the _whole_ ancestry!), in which the file _was_ present, so you literally _added_ something _on top_ of the old revision.

Hth, Dscho