Re: Extracting a file

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Jeff King <peff@peff.net> 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