On Sat, Jan 13, 2007 at 12:17:18PM +0100, Johannes Schindelin wrote:
quoted text
> Hi,
> 
> On Sat, 13 Jan 2007, Peter Baumann wrote:
> 
> > 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). 
> 
OK. Now we are talking clear. I don't like git-add to do two things (see
below)

quoted text
> 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.
> 

I unterstand the concept of the index, I even glanced at the code. The
index holds for every file... err..  content a struct cache_entry (my
above mentioned "buckets"). If I add a new cache_entry, I enlarge my
later committed tree by at least one new file (adding a new file could
also add an entry for a directory in the final tree object).

I would much more like the idea of having one command (git-add) which
would enlarge the index by a new struct cache_entry and another which
replaces a previously added cache_entry. Because I'd like to control
how my final tree looks like and add least to me adding a file entry to
a tree is something different than updating a file entry (at least
mentally).

I'd favour the following model:

 git-add: register the content of a previously unkown file to git
    (there was now struct chache_entry in the index previously which
     described a file with the same name)

 git-rm: remove a struct cache_entry from the index and after some
    safty checks remove the file, too. (see in the mailinglist archive;
    there was much talk about git-rm and its semantic)

 git-refresh (or git-stage or git-update or what-ever you call it):
    replace the cache_entry by a new one

And this all about content; the content which would represent my next
tree object. Because developers don't think of "add" if they want to
remove a file from the commit. If the power users liked to have only one
command, wich does remove, add and update then lets not call it add.
Better make this commmand the above mentioned git-refresh which would do
"the right thing" if called with a new file/removed file

Im simply think its confusing to call the described command git-add, as
we have it now. It's at least *very* confusing for new starters.

-Peter

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