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