Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 20, 2005, 01:51 UTC
Message-ID: <Pine.LNX.4.58.0504191846290.6467@ppc970.osdl.org>
In-Reply-To: <7vacnumgot.fsf@assigned-by-dhcp.cox.net>

On Tue, 19 Apr 2005, Junio C Hamano wrote:

> 
> Let's for a moment forget what git-pasky currently does, which
> is not to touch .git/index until the user says "Ok, let's
> commit".

I think git-pasky is wrong.

It's true that we want to often (almost always) diff against the last "released" thing, and I actually think git-pasky does what it does because I never wrote a tool to diff the current working directory against a "tree".

At the same time, I very much worked with a model where you do _not_ have a traditional "work file", but the index really _is_ the "work file".

Show 6 quoted lines

> I'd like to start from a different premise and see what happens:
> 
>  - What .git/index records is *not* the state as the last
>    commit.  It is just an cache Cogito uses to speed up access
>    to the user's working tree.  From the user's point of view,
>    it does not even exist.

Yes. Yes. YES.

That is indeed the whole point of the index file. In my world-view, the index file does _everything_. It's the staging area ("work file"), it's the merging area ("merge directory") and it's the cache file ("stat cache").

I'll immediately write a tool to diff the current working directory against a tree object, and hopefully that will just make pasky happy with this model too.

Is there any other reason why git-pasky wants to have a work file?

		Linus