{"thread":{"id":"56143","subject":"Extracting a file","startedAt":"2021-07-22T08:49:17Z","lastAt":"2021-07-23T18:17:07Z","messageCount":8,"participants":["Angelo Borsotti","Ævar Arnfjörð Bjarmason","Jeff King","Junio C Hamano","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"430896","messageId":"CAB9Jk9AafnUQr6q8t=b4Dh0PZHUA=fKJmtXxxObuGpF_w-_2wQ@mail.gmail.com","threadId":"56143","inReplyTo":null,"subject":"Extracting a file","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2021-07-22T08:48:59Z","receivedAt":"2021-07-22T08:49:17Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi,\n\nsometimes there is a need to extract a file from a commit.\nE.g. some changes have been applied to it in the work directory,\nand the app being implemented no longer works properly.\nIt would be fine to have a look at that file, some commits ago,\nwhen all worked fine.\nOf course, it is possible to recover the entire old commit, or to\nmake a new branch, or checkout the file (which requires to save\nthe new one before), but the most simple and safe way is to\nextract the file, giving it a new name.\nThat is possible, using this (hard to remember) trick:\n\ngit show HASH:file/path/name.ext > some_new_name.ext\n\nWould not be better to have a \"copy\" command to copy a file from a commit\nto a new one in the current directory?\nThis would make a git repository resemble a (readonly) filesystem, which\nactually it is.\nNote also that the ability to get from a repository what one has stored\nin it is the most basic feature anyone wants from a repository.\n\nThank you\n-Angelo Borsotti\n"},{"id":"430899","messageId":"871r7qvhhr.fsf@evledraar.gmail.com","threadId":"56143","inReplyTo":"CAB9Jk9AafnUQr6q8t=b4Dh0PZHUA=fKJmtXxxObuGpF_w-_2wQ@mail.gmail.com","subject":"Re: Extracting a file","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-22T09:05:58Z","receivedAt":"2021-07-22T09:13:10Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jul 22 2021, Angelo Borsotti wrote:\n\n> Hi,\n>\n> sometimes there is a need to extract a file from a commit.\n> E.g. some changes have been applied to it in the work directory,\n> and the app being implemented no longer works properly.\n> It would be fine to have a look at that file, some commits ago,\n> when all worked fine.\n> Of course, it is possible to recover the entire old commit, or to\n> make a new branch, or checkout the file (which requires to save\n> the new one before), but the most simple and safe way is to\n> extract the file, giving it a new name.\n> That is possible, using this (hard to remember) trick:\n>\n> git show HASH:file/path/name.ext > some_new_name.ext\n>\n> Would not be better to have a \"copy\" command to copy a file from a commit\n> to a new one in the current directory?\n\nThat's an interesting feature request, FWIW you can do this now with:\n\n git mv A B &&\n git checkout HEAD -- A\n\nI wonder if having a \"git copy\" for that would be more confusing that\nnot, i.e. a frequent difficulty new users used to have with git if they\nwere used to cvs/svn was to look for a \"copy\" command, thinking that\ngit's data model (like those older VCS's) needed the user to use a \"mv\"\nor \"copy\" to track history.\n\nOn the other hand perhaps git's so thoroughly established that it's not\nmuch of an educational issue anymore.\n\n> This would make a git repository resemble a (readonly) filesystem, which\n> actually it is.\n> Note also that the ability to get from a repository what one has stored\n> in it is the most basic feature anyone wants from a repository.\n\nGit is actively not such a \"read-only FS\" in the sense of some version\ncontrol systems, i.e. needing to declare that you are now going to\n\"edit\" the file etc.\n\nIt is for bare repositories, but a checkout explicitly concerns itself\nwith you doing arbitrary changes on the FS, and git needing to keep up.\n\nSo maybe there should be a \"copy\", but if your starting point for\nwanting it is to make git behave like a read-only FS I don't think\nthat'll lead anywhere productive.\n"},{"id":"430902","messageId":"CAB9Jk9DqCR8C9qx6-gZmpTQfBAKnEupQTb1WkJgN3YOqSO0=2A@mail.gmail.com","threadId":"56143","inReplyTo":"871r7qvhhr.fsf@evledraar.gmail.com","subject":"Re: Extracting a file","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2021-07-22T09:46:01Z","receivedAt":"2021-07-22T09:46:17Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi,\n\nthank you for your quick reply.\n\nActually, I did not want to make git behave like a read-only filesystem,\nbut only to be able to get what is stored in it using some easy to remember\ncommand.\n\nI guess that:\n\n git mv A B &&\n git checkout HEAD -- A\n\nrenames file A in the work, current, directory to B, and then recovers\nA from the\nrepository. This changes the file on which I am working. After having\nread the old\nA, and understood what changes I make that are not correct, I should delete A,\nand rename B back to A.\nIf something gets wrong with this, I risk to damage my original A.\nThis is why it is\nbetter not to change it, and instead get a copy of the old one with\nanother name,\nwhich is what\n\ngit show HASH:file/path/name.ext > some_new_name.ext\n\ndoes.\n\n-Angelo\n\nOn Thu, 22 Jul 2021 at 11:13, Ævar Arnfjörð Bjarmason wrote:\n>\n>\n> On Thu, Jul 22 2021, Angelo Borsotti wrote:\n>\n> > Hi,\n> >\n> > sometimes there is a need to extract a file from a commit.\n> > E.g. some changes have been applied to it in the work directory,\n> > and the app being implemented no longer works properly.\n> > It would be fine to have a look at that file, some commits ago,\n> > when all worked fine.\n> > Of course, it is possible to recover the entire old commit, or to\n> > make a new branch, or checkout the file (which requires to save\n> > the new one before), but the most simple and safe way is to\n> > extract the file, giving it a new name.\n> > That is possible, using this (hard to remember) trick:\n> >\n> > git show HASH:file/path/name.ext > some_new_name.ext\n> >\n> > Would not be better to have a \"copy\" command to copy a file from a commit\n> > to a new one in the current directory?\n>\n> That's an interesting feature request, FWIW you can do this now with:\n>\n> git mv A B &&\n> git checkout HEAD -- A\n>\n> I wonder if having a \"git copy\" for that would be more confusing that\n> not, i.e. a frequent difficulty new users used to have with git if they\n> were used to cvs/svn was to look for a \"copy\" command, thinking that\n> git's data model (like those older VCS's) needed the user to use a \"mv\"\n> or \"copy\" to track history.\n>\n> On the other hand perhaps git's so thoroughly established that it's not\n> much of an educational issue anymore.\n>\n> > This would make a git repository resemble a (readonly) filesystem, which\n> > actually it is.\n> > Note also that the ability to get from a repository what one has stored\n> > in it is the most basic feature anyone wants from a repository.\n>\n> Git is actively not such a \"read-only FS\" in the sense of some version\n> control systems, i.e. needing to declare that you are now going to\n> \"edit\" the file etc.\n>\n> It is for bare repositories, but a checkout explicitly concerns itself\n> with you doing arbitrary changes on the FS, and git needing to keep up.\n>\n> So maybe there should be a \"copy\", but if your starting point for\n> wanting it is to make git behave like a read-only FS I don't think\n> that'll lead anywhere productive.\n"},{"id":"430982","messageId":"YPppNYOO26xAq2fn@coredump.intra.peff.net","threadId":"56143","inReplyTo":"CAB9Jk9DqCR8C9qx6-gZmpTQfBAKnEupQTb1WkJgN3YOqSO0=2A@mail.gmail.com","subject":"Re: Extracting a file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-23T07:01:09Z","receivedAt":"2021-07-23T07:01:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 22, 2021 at 11:46:01AM +0200, Angelo Borsotti wrote:\n\n> Actually, I did not want to make git behave like a read-only filesystem,\n> but only to be able to get what is stored in it using some easy to remember\n> command.\n> \n> I guess that:\n> \n> git mv A B &&\n> git checkout HEAD -- A\n> \n> renames file A in the work, current, directory to B, and then recovers\n> A from the\n> repository. This changes the file on which I am working. After having\n> read the old\n> A, and understood what changes I make that are not correct, I should delete A,\n> and rename B back to A.\n> If something gets wrong with this, I risk to damage my original A.\n> This is why it is\n> better not to change it, and instead get a copy of the old one with\n> another name,\n> which is what\n> \n> git show HASH:file/path/name.ext > some_new_name.ext\n\nYou might also like \"git checkout -p HASH -- A\", which will let you pick\nindividual hunks from HASH:A and apply them to your working tree.\n\n-Peff\n"},{"id":"430989","messageId":"CAB9Jk9Af-GKFUQCiyN9fKmjA1hOLBw9mc_FPFBHX1m1NAnbfmQ@mail.gmail.com","threadId":"56143","inReplyTo":"YPppNYOO26xAq2fn@coredump.intra.peff.net","subject":"Re: Extracting a file","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2021-07-23T07:38:41Z","receivedAt":"2021-07-23T07:38:57Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi,\n\n> You might also like \"git checkout -p HASH -- A\", which will let you pick\n> individual hunks from HASH:A and apply them to your working tree.\n\nThis shows the differences between the committed and the current file,\nin a patch\nform, which is handy to apply to the current file to make it equal to\nthe old, but\nnot if I want to browse the old file and understand how it was before.\nMoreover, the command ends by asking:\n\n Apply deletion to index and worktree [y,n,q,a,d,?]?\n\nand when I must be very careful to provide the correct answer so as not to\ndamage my files.\nSo many alternatives to simply get a file from the repo, some of which\npotentially\ndangerous, show that there is a need for a simple, safe command to get it.\n\n-Angelo\n\nOn Fri, 23 Jul 2021 at 09:01, Jeff King wrote:\n>\n> On Thu, Jul 22, 2021 at 11:46:01AM +0200, Angelo Borsotti wrote:\n>\n> > Actually, I did not want to make git behave like a read-only filesystem,\n> > but only to be able to get what is stored in it using some easy to remember\n> > command.\n> >\n> > I guess that:\n> >\n> > git mv A B &&\n> > git checkout HEAD -- A\n> >\n> > renames file A in the work, current, directory to B, and then recovers\n> > A from the\n> > repository. This changes the file on which I am working. After having\n> > read the old\n> > A, and understood what changes I make that are not correct, I should delete A,\n> > and rename B back to A.\n> > If something gets wrong with this, I risk to damage my original A.\n> > This is why it is\n> > better not to change it, and instead get a copy of the old one with\n> > another name,\n> > which is what\n> >\n> > git show HASH:file/path/name.ext > some_new_name.ext\n>\n> You might also like \"git checkout -p HASH -- A\", which will let you pick\n> individual hunks from HASH:A and apply them to your working tree.\n>\n> -Peff\n"},{"id":"431052","messageId":"xmqqa6mdou3n.fsf@gitster.g","threadId":"56143","inReplyTo":"CAB9Jk9Af-GKFUQCiyN9fKmjA1hOLBw9mc_FPFBHX1m1NAnbfmQ@mail.gmail.com","subject":"Re: Extracting a file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-23T16:47:24Z","receivedAt":"2021-07-23T16:47:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Angelo Borsotti writes:\n\n>> You might also like \"git checkout -p HASH -- A\", which will let you pick\n>> individual hunks from HASH:A and apply them to your working tree.\n>\n> This shows the differences between the committed and the current file,\n> in a patch\n> form, which is handy to apply to the current file to make it equal to\n> the old, but\n> not if I want to browse the old file and understand how it was before.\n\nWhy doesn't a straight-forward \"check out the path from an old\nversion\" work? That is\n\n git checkout $old_version -- path/to/file.ext\n\nIs it because you have changes to path/to/file.ext already (in which\ncase \"mv path/to/file.ext path/to/file.ext-saved\" would be a quick\nway to save it away)?\n\nAnd then path/to/file.ext can be inspected to your heart's content,\nand when you are done and want to go back to the current state, you\ncan do \"git checkout HEAD -- path/to/file.ext\" (followed by the\nearlier \"mv\" in reverse)?\n"},{"id":"431054","messageId":"xmqq5yx1oty6.fsf@gitster.g","threadId":"56143","inReplyTo":"YPppNYOO26xAq2fn@coredump.intra.peff.net","subject":"Re: Extracting a file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-23T16:50:41Z","receivedAt":"2021-07-23T16:50:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Jul 22, 2021 at 11:46:01AM +0200, Angelo Borsotti wrote:\n>\n>> Actually, I did not want to make git behave like a read-only filesystem,\n>> but only to be able to get what is stored in it using some easy to remember\n>> command.\n>> \n>> I guess that:\n>> \n>> git mv A B &&\n>> git checkout HEAD -- A\n>> \n>> renames file A in the work, current, directory to B, and then recovers\n>> A from the\n>> repository. This changes the file on which I am working. After having\n>> read the old\n>> A, and understood what changes I make that are not correct, I should delete A,\n>> and rename B back to A.\n>> If something gets wrong with this, I risk to damage my original A.\n>> This is why it is\n>> better not to change it, and instead get a copy of the old one with\n>> another name,\n>> which is what\n>> \n>> git show HASH:file/path/name.ext > some_new_name.ext\n>\n> You might also like \"git checkout -p HASH -- A\", which will let you pick\n> individual hunks from HASH:A and apply them to your working tree.\n\nThere is\n\n git cat-file --textconv --filters HASH:A >my-temporary-file-to-inspect\n\nwhich would not touch the index or any tracked working tree file,\nother than the target of redirection.\n\n"},{"id":"431076","messageId":"60fb079e38977_defb2087d@natae.notmuch","threadId":"56143","inReplyTo":"xmqq5yx1oty6.fsf@gitster.g","subject":"Re: Extracting a file","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-23T18:17:02Z","receivedAt":"2021-07-23T18:17:07Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > On Thu, Jul 22, 2021 at 11:46:01AM +0200, Angelo Borsotti wrote:\n> >\n> >> Actually, I did not want to make git behave like a read-only filesystem,\n> >> but only to be able to get what is stored in it using some easy to remember\n> >> command.\n> >> \n> >> I guess that:\n> >> \n> >> git mv A B &&\n> >> git checkout HEAD -- A\n> >> \n> >> renames file A in the work, current, directory to B, and then recovers\n> >> A from the\n> >> repository. This changes the file on which I am working. After having\n> >> read the old\n> >> A, and understood what changes I make that are not correct, I should delete A,\n> >> and rename B back to A.\n> >> If something gets wrong with this, I risk to damage my original A.\n> >> This is why it is\n> >> better not to change it, and instead get a copy of the old one with\n> >> another name,\n> >> which is what\n> >> \n> >> git show HASH:file/path/name.ext > some_new_name.ext\n> >\n> > You might also like \"git checkout -p HASH -- A\", which will let you pick\n> > individual hunks from HASH:A and apply them to your working tree.\n> \n> There is\n> \n> git cat-file --textconv --filters HASH:A >my-temporary-file-to-inspect\n> \n> which would not touch the index or any tracked working tree file,\n> other than the target of redirection.\n\nHmm, --textconv and --filters are incompatible with each other, did you\nmean \"--textconv | --filters\"?\n\nAlso, this is simpler:\n\n git cat-file -p HASH:A\n\nAlthough I don't know how that's better than Angelo's `git show`.\n\nFTR I do often use `git show commit:file` myself. I'm not sure if\nwe could do something particularly better than that.\n\n-- \nFelipe Contreras\n"}]}