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

From: Junio C Hamano <junkio@cox.net>
Date: Jan 13, 2007, 18:01 UTC
Message-ID: <7v1wlylsa8.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070113093322.GA4825@xp.machine.xx>

Peter Baumann <waste.manager@gmx.de> writes:

Show 5 quoted lines

> 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. And that has nothing to do with
> files (or at least the silly me can't grok it).

To put this silly naming argument to the rest for now, because I am not going to change add/rm nor introduce refresh, at least during this round, so keeping this thread alive would just waste everybody's time doing mental masturbation.

Physically the index is represented as a list of <blob object name, pathname> tuples. When we say "git tracks contents", however, we look at it as if content of each blob object is just a bytestream labeled with the pathname.

When you say "git-update-index file" (without --add/--remove), what happens is "UPDATE" (in SQL sense). The part of the data recorded in the current index that is labeled with "file" is replaced with what is from the working tree.

The --add option changes the "UPDATE" to "INSERT OR REPLACE". It allows contents that are labelled with a pathname that does not yet exist in the index. What --remove does is to allow it to also "DELETE".

So there _is_ a distinction between adding new pathname and updating the contents at the low level.

However, if you look at the way 'git-update-index' is used in the Porcelain-ish scripts (now you would need to go back and examine a bit older versions of git, since many commands have been rewritten in C to become built-in and we use update-index in much fewer places in today's version), we almost always used update-index with --add when talking about the set of paths the end user talks about ('am' and 'applypatch' uses --index-info; this is also "INSERT OR REPLACE" operation primarily). The places we did not, we knew we were only dealing with known set of paths taken from the current index, so they also could have had --add without any ill effects.

In other words, there was not much need for "UPDATE only, please do not INSERT" in practice.

That's primarily why the higher level interface git-add / git-mv does not expose that distinction; git-add will do "INSERT OR REPLACE". git-rm will do "DELETE", and there will be no higher level to only do "UPDATE".