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.
next prev parent 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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).