Re: Extracting a file

From: Angelo Borsotti <angelo.borsotti@gmail.com>
Date: Jul 22, 2021, 09:46 UTC
Message-ID: <CAB9Jk9DqCR8C9qx6-gZmpTQfBAKnEupQTb1WkJgN3YOqSO0=2A@mail.gmail.com>
In-Reply-To: <871r7qvhhr.fsf@evledraar.gmail.com>

Hi,

thank you for your quick reply.

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

does.

-Angelo

On Thu, 22 Jul 2021 at 11:13, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 51 quoted lines

>
>
> On Thu, Jul 22 2021, Angelo Borsotti wrote:
>
> > Hi,
> >
> > sometimes there is a need to extract a file from a commit.
> > E.g. some changes have been applied to it in the work directory,
> > and the app being implemented no longer works properly.
> > It would be fine to have a look at that file, some commits ago,
> > when all worked fine.
> > Of course, it is possible to recover the entire old commit, or to
> > make a new branch, or checkout the file (which requires to save
> > the new one before), but the most simple and safe way is to
> > extract the file, giving it a new name.
> > That is possible, using this (hard to remember) trick:
> >
> > git show HASH:file/path/name.ext > some_new_name.ext
> >
> > Would not be better to have a "copy" command to copy a file from a commit
> > to a new one in the current directory?
>
> That's an interesting feature request, FWIW you can do this now with:
>
>     git mv A B &&
>     git checkout HEAD -- A
>
> I wonder if having a "git copy" for that would be more confusing that
> not, i.e. a frequent difficulty new users used to have with git if they
> were used to cvs/svn was to look for a "copy" command, thinking that
> git's data model (like those older VCS's) needed the user to use a "mv"
> or "copy" to track history.
>
> On the other hand perhaps git's so thoroughly established that it's not
> much of an educational issue anymore.
>
> > This would make a git repository resemble a (readonly) filesystem, which
> > actually it is.
> > Note also that the ability to get from a repository what one has stored
> > in it is the most basic feature anyone wants from a repository.
>
> Git is actively not such a "read-only FS" in the sense of some version
> control systems, i.e. needing to declare that you are now going to
> "edit" the file etc.
>
> It is for bare repositories, but a checkout explicitly concerns itself
> with you doing arbitrary changes on the FS, and git needing to keep up.
>
> So maybe there should be a "copy", but if your starting point for
> wanting it is to make git behave like a read-only FS I don't think
> that'll lead anywhere productive.