> "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>
> "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
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
> "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'
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
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
6 matches
Mail list logo