Hi,
> 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.
This shows the differences between the committed and the current file,
in a patch
form, which is handy to apply to the current file to make it equal to
the old, but
not if I want to browse the old file and understand how it was before.
Moreover, the command ends by asking:
Apply deletion to index and worktree [y,n,q,a,d,?]?
and when I must be very careful to provide the correct answer so as not to
damage my files.
So many alternatives to simply get a file from the repo, some of which
potentially
dangerous, show that there is a need for a simple, safe command to get it.
-Angelo
On Fri, 23 Jul 2021 at 09:01, Jeff King <peff@xxxxxxxx> wrote:
>
> 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.
>
> -Peff
