Re: GIT - breaking backward compatibility

From: Junio C Hamano <junkio@cox.net>
Date: Sep 20, 2005, 06:19 UTC
Message-ID: <7vu0gg8dmv.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <432F8C33.5080603@didntduck.org>

Brian Gerst <bgerst@didntduck.org> writes:

> Junio C Hamano wrote:

[Long quotation snipped]

Brian, you did not have to quote the whole thing if you wanted to respond to only one bullet point in my footnotes.

Show 10 quoted lines

> Essentially what I want to do is:
>
> git-ls-files --others | xargs git-update-index --add --
> git-ls-files --deleted | xargs git-update-index --remove --
> git-ls-files --modified | xargs git-update-index --
>
> This will completely resync the index and cache to the working tree 
> state after applying a patch.  git-update-index --refresh only updates 
> the stat info in the index.  It does _not_ write a new cache object if 
> the file contents have actually changed.

First of all, what I meant to say with 'update-index --refresh' was not the refreshing part itself, but the fact that says 'needs update' -- meaning it knows those paths have been truly modified.

Forgetting 'use git-apply' comment from Linus for now,... if you are going to do the above in separate steps, then the last one is already available (but not as an option to 'git-ls-files'):

    git-diff-files -r --name-only -z | xargs -0 git-update-index --

> If your objection is to calling the files modifed, then call it dirty or 
> something else.

I was not talking about the name, but the semantics.

* The user may be interested in cache-dirty files, but I suspect
  that is a very limited audience.  I do not offhand think of a
  good reason to want to know which files are cache-dirty
  without wanting to know if they are really modified, except
  when debugging git itself.  If you really want to know that,
  you can always say `git-diff-files`, or if you want to be
  pickier, `git-diff-files --diff-filter=M --name-only`.

* Showing a list of *truly* 'modified' files, disregarding the
  false hits from cache-dirty but otherwise unmodified files,
  would be another useful thing.  But that is something
  `git-update-cache --refresh` already gives you.

* As a front-end, `git status` shows you list of modifications
  between HEAD and cache, and between cache and working tree.
  The latter is done with `git-diff-files` after running
  `git-update-cache --refresh`.  This probably gives the most
  useful information to the end user.

Having said all that, `git-ls-files`, especially with `-t` flag, is a handy way to know the status of all files in the working tree with a single command. What it does not currently give us that would be nicer to have as an addition is not cache-dirty status, but *true* 'modified' flag. Although this is something available from `git-update-cache --refresh` as I said earlier, it would still be nice to be able to get it out of a single command invocation, together with files in other status.

So that is what I have on the proposed updates branch tonight. Does it more-or-less do what you wanted?