* Extracting a file @ 2021-07-22 8:48 Angelo Borsotti 2021-07-22 9:05 ` Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 8+ messages in thread From: Angelo Borsotti @ 2021-07-22 8:48 UTC (permalink / raw) To: git 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? 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. Thank you -Angelo Borsotti ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extracting a file 2021-07-22 8:48 Extracting a file Angelo Borsotti @ 2021-07-22 9:05 ` Ævar Arnfjörð Bjarmason 2021-07-22 9:46 ` Angelo Borsotti 0 siblings, 1 reply; 8+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2021-07-22 9:05 UTC (permalink / raw) To: Angelo Borsotti; +Cc: git 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extracting a file 2021-07-22 9:05 ` Ævar Arnfjörð Bjarmason @ 2021-07-22 9:46 ` Angelo Borsotti 2021-07-23 7:01 ` Jeff King 0 siblings, 1 reply; 8+ messages in thread From: Angelo Borsotti @ 2021-07-22 9:46 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: git 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: > > > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extracting a file 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:50 ` Junio C Hamano 0 siblings, 2 replies; 8+ messages in thread From: Jeff King @ 2021-07-23 7:01 UTC (permalink / raw) To: Angelo Borsotti; +Cc: Ævar Arnfjörð Bjarmason, git 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extracting a file 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 1 sibling, 1 reply; 8+ messages in thread From: Angelo Borsotti @ 2021-07-23 7:38 UTC (permalink / raw) To: Jeff King; +Cc: Ævar Arnfjörð Bjarmason, git 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@peff.net> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extracting a file 2021-07-23 7:38 ` Angelo Borsotti @ 2021-07-23 16:47 ` Junio C Hamano 0 siblings, 0 replies; 8+ messages in thread From: Junio C Hamano @ 2021-07-23 16:47 UTC (permalink / raw) To: Angelo Borsotti; +Cc: Jeff King, Ævar Arnfjörð Bjarmason, git Angelo Borsotti <angelo.borsotti@gmail.com> writes: >> 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. Why doesn't a straight-forward "check out the path from an old version" work? That is git checkout $old_version -- path/to/file.ext Is it because you have changes to path/to/file.ext already (in which case "mv path/to/file.ext path/to/file.ext-saved" would be a quick way to save it away)? And then path/to/file.ext can be inspected to your heart's content, and when you are done and want to go back to the current state, you can do "git checkout HEAD -- path/to/file.ext" (followed by the earlier "mv" in reverse)? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extracting a file 2021-07-23 7:01 ` Jeff King 2021-07-23 7:38 ` Angelo Borsotti @ 2021-07-23 16:50 ` Junio C Hamano 2021-07-23 18:17 ` Felipe Contreras 1 sibling, 1 reply; 8+ messages in thread From: Junio C Hamano @ 2021-07-23 16:50 UTC (permalink / raw) To: Jeff King; +Cc: Angelo Borsotti, Ævar Arnfjörð Bjarmason, git Jeff King <peff@peff.net> writes: > 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. There is git cat-file --textconv --filters HASH:A >my-temporary-file-to-inspect which would not touch the index or any tracked working tree file, other than the target of redirection. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extracting a file 2021-07-23 16:50 ` Junio C Hamano @ 2021-07-23 18:17 ` Felipe Contreras 0 siblings, 0 replies; 8+ messages in thread From: Felipe Contreras @ 2021-07-23 18:17 UTC (permalink / raw) To: Junio C Hamano, Jeff King Cc: Angelo Borsotti, Ævar Arnfjörð Bjarmason, git Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > 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. > > There is > > git cat-file --textconv --filters HASH:A >my-temporary-file-to-inspect > > which would not touch the index or any tracked working tree file, > other than the target of redirection. Hmm, --textconv and --filters are incompatible with each other, did you mean "--textconv | --filters"? Also, this is simpler: git cat-file -p HASH:A Although I don't know how that's better than Angelo's `git show`. FTR I do often use `git show commit:file` myself. I'm not sure if we could do something particularly better than that. -- Felipe Contreras ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-07-23 18:17 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-22 8:48 Extracting a file Angelo Borsotti 2021-07-22 9:05 ` Ævar Arnfjörð Bjarmason 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
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).