On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano <gits...@pobox.com> wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >>> $ git rm -r --cached . && git add . >> >> (Both should work) >> >> To be honest, from the documentation, I can't figure out the difference >> between >> $ git read-tree --empty >> and >> $ git rm -r --cached . >> >> Does anybody remember the discussion, why we ended up with read-tree ? > > We used to use neither, and considered it fine to "rm .git/index" if > you wanted to empty the on-disk index file in the old world. In the > modern world, folks want you to avoid touching filesystem directly > and instead want you to use Git tools, and the above are two obvious > ways to do so. > > "git read-tree" (without any parameter, i.e. "read these 0 trees and > populate the index with it") and its modern and preferred synonym > "git read-tree --empty" (i.e. "I am giving 0 trees and I know the > sole effect of this command is to empty the index.") are more direct > ways to express "I want the index emptied" between the two. > > The other one, "git rm -r --cached .", in the end gives you the same > state because it tells Git to "iterate over all the entries in the > index, find the ones that match pathspec '.', and remove them from > the index.". It is not wrong per-se, but conceptually it is a bit > roundabout way to say that "I want the index emptied", I would > think. > > I wouldn't be surprised if the "rm -r --cached ." were a lot slower, > due to the overhead of having to do the pathspec filtering that ends > up to be a no-op, but there shouldn't be a difference in the end > result.
Sorry to bring this old thread back to life, but I did notice that this causes file modes to reset back to 644 (from 755) on Windows version of Git. Is there a way to `$ git read-tree --empty && git add .` without mucking with file permissions?
