Thread (1 message) 1 message, 1 author, 2016-06-15

Re: GIT - breaking backward compatibility

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:06

Brian Gerst [off-list ref] 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.
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help