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

From: Peter Baumann <siprbaum@stud.informatik.uni-erlangen.de>
Date: Jan 13, 2007, 16:19 UTC
Message-ID: <20070113161936.GB4825@xp.machine.xx>
In-Reply-To: <Pine.LNX.4.63.0701131204511.22628@wbgn013.biozentrum.uni-wuerzburg.de>

On Sat, Jan 13, 2007 at 12:17:18PM +0100, Johannes Schindelin wrote:

Show 36 quoted lines

> 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)

Show 7 quoted lines

> 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

Show 11 quoted lines

> 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
>