Re: Extracting a file

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 22, 2021, 09:05 UTC
Message-ID: <871r7qvhhr.fsf@evledraar.gmail.com>
In-Reply-To: <CAB9Jk9AafnUQr6q8t=b4Dh0PZHUA=fKJmtXxxObuGpF_w-_2wQ@mail.gmail.com>

On Thu, Jul 22 2021, Angelo Borsotti wrote:

Show 17 quoted lines

> 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.