All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Angelo Borsotti <angelo.borsotti@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: Extracting a file
Date: Thu, 22 Jul 2021 11:05:58 +0200	[thread overview]
Message-ID: <871r7qvhhr.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAB9Jk9AafnUQr6q8t=b4Dh0PZHUA=fKJmtXxxObuGpF_w-_2wQ@mail.gmail.com>


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.

  reply	other threads:[~2021-07-22  9:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-22  8:48 Extracting a file Angelo Borsotti
2021-07-22  9:05 ` Ævar Arnfjörð Bjarmason [this message]
2021-07-22  9:46   ` Angelo Borsotti
2021-07-23  7:01     ` Jeff King
2021-07-23  7:38       ` Angelo Borsotti
2021-07-23 16:47         ` Junio C Hamano
2021-07-23 16:50       ` Junio C Hamano
2021-07-23 18:17         ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871r7qvhhr.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=angelo.borsotti@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.