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 

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

> 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

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?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to