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

2005-04-20 Thread Junio C Hamano
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes: LT> And as you can see, the output matches "diff-tree -r" output (we always do LT> "-r", since the index is always fully populated). All the same rules: "+" LT> means added file, "-" means removed file, and "*" means changed file. You LT>

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

2005-04-19 Thread Junio C Hamano
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes: >> 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. The model you have always had is that there are three things the user

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

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Linus Torvalds wrote: > > 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

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

2005-04-19 Thread Junio C Hamano
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes: LT> Is there any other reason why git-pasky wants to have a work file? Do you mean "why does a user wants to check things out in the working directory and make changes, possibly run compile tests before pushing the result to Linus?" ;-) I'

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

2005-04-19 Thread Linus Torvalds
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" th

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

2005-04-19 Thread Junio C Hamano
I was reading this comment in gitcommit.sh and started thinking... # We bother with added/removed files here instead of updating # the cache at the time of git(add|rm).sh, since we want to # have the cache in a consistent state representing the tree # as it was the last time we com