Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > On Thu, Jul 22, 2021 at 11:46:01AM +0200, Angelo Borsotti wrote: > > > >> Actually, I did not want to make git behave like a read-only filesystem, > >> but only to be able to get what is stored in it using some easy to remember > >> command. > >> > >> I guess that: > >> > >> git mv A B && > >> git checkout HEAD -- A > >> > >> renames file A in the work, current, directory to B, and then recovers > >> A from the > >> repository. This changes the file on which I am working. After having > >> read the old > >> A, and understood what changes I make that are not correct, I should delete A, > >> and rename B back to A. > >> If something gets wrong with this, I risk to damage my original A. > >> This is why it is > >> better not to change it, and instead get a copy of the old one with > >> another name, > >> which is what > >> > >> git show HASH:file/path/name.ext > some_new_name.ext > > > > You might also like "git checkout -p HASH -- A", which will let you pick > > individual hunks from HASH:A and apply them to your working tree. > > There is > > git cat-file --textconv --filters HASH:A >my-temporary-file-to-inspect > > which would not touch the index or any tracked working tree file, > other than the target of redirection. Hmm, --textconv and --filters are incompatible with each other, did you mean "--textconv | --filters"? Also, this is simpler: git cat-file -p HASH:A Although I don't know how that's better than Angelo's `git show`. FTR I do often use `git show commit:file` myself. I'm not sure if we could do something particularly better than that. -- Felipe Contreras
