Peter Baumann <waste.manager@xxxxxx> writes:
> 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".
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html