{"thread":{"id":"7906","subject":"git-rev-parse(1) questions","startedAt":"2007-04-30T18:24:52Z","lastAt":"2007-04-30T20:20:35Z","messageCount":4,"participants":["Jari Aalto","Linus Torvalds","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40749","messageId":"mz0pwwi3.fsf@cante.net","threadId":"7906","inReplyTo":null,"subject":"git-rev-parse(1) questions","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-04-30T18:24:52Z","receivedAt":"2007-04-30T18:24:52Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"\nCould someone provide example commands where and how to use these:\n\n * A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{})\n means the object could be a tag, and dereference the tag\n recursively until a non-tag object is found.\n\n * A colon, optionally followed by a stage number (0 to 3) and a\n colon, followed by a path; this names a blob object in the index\n at the given path. Missing stage number (and the colon that\n follows it) names an stage 0 entry.\n\nJari\n"},{"id":"40751","messageId":"alpine.LFD.0.98.0704301138320.3419@woody.linux-foundation.org","threadId":"7906","inReplyTo":"mz0pwwi3.fsf@cante.net","subject":"Re: git-rev-parse(1) questions","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-30T18:49:06Z","receivedAt":"2007-04-30T18:49:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 30 Apr 2007, Jari Aalto wrote:\n>\n> Could someone provide example commands where and how to use these:\n> \n> * A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{})\n> means the object could be a tag, and dereference the tag\n> recursively until a non-tag object is found.\n\nI don't think you'd normally use this much. It's more visible in things \nlike\n\n\tgit ls-remote \n\nwhich will show tags and the objects they derefernce to, using the \"^{}\" \nsyntax. Normally you'd not use it in any day-to-day operation, although if \nyou want to, you could for example use\n\n\tgit show tag^{}\n\nto show what the tag points to, without getting the tag part.\n\nFor an example, of this, in the git archive, do\n\n\tgit show junio-gpg-pub\nvs\n\tgit show junio-gpg-pub^{}\n\nand think about the difference in output.\n\nBut no, you'd not normally use this outside of scripts (and even inside \nscripts, it's much more common to instead use \"tag^0\", which does \neffectively the same *but* also requires the thing to be a commit.\n\n> * A colon, optionally followed by a stage number (0 to 3) and a\n> colon, followed by a path; this names a blob object in the index\n> at the given path. Missing stage number (and the colon that\n> follows it) names an stage 0 entry.\n\nYou'd never use this unless you're working with a unmerged tree entry, and \nthen you can use it for things like\n\n\tgit diff :1:my-path :2:their-path\n\nif you want to look at the differences between the two blobs that are \nunmerged, and come from different branches (\":1:my-path\" comes from the \nbranch you were merging things into,and the \":2:their-path\" comes from the \nbranch you were merging from).\n\nThat can be useful in the extremely rare case where you had criss-crossing \nrenames, for example, and the recursive merge strategy couldn't resolve \nthem, and you realize that in order to merge it properly you'll need to \nlook at different pathnames that didn't pair up.\n\nNormally, if the pathnames pair up, you'd normally just get a nice data \nconflict and you'd likely just work with that. \n\nI don't think anybody ever _normally_ uses the :n:path syntax. It's really \na very esoteric capability for when things go really really wrong, and you \nwant to see what the different stages contain.\n\n\t\tLinus\n"},{"id":"40752","messageId":"Pine.LNX.4.64.0704302036520.29859@racer.site","threadId":"7906","inReplyTo":"mz0pwwi3.fsf@cante.net","subject":"Re: git-rev-parse(1) questions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-30T18:51:48Z","receivedAt":"2007-04-30T18:51:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 30 Apr 2007, Jari Aalto wrote:\n\n> Could someone provide example commands where and how to use these:\n> \n> * A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{})\n> means the object could be a tag, and dereference the tag\n> recursively until a non-tag object is found.\n\nYou can get at the _commit_ tagged with version 1.0.0 by doing \"git \nrev-parse v1.0.0^{}\" (as opposed to the tag object).\n\n> * A colon, optionally followed by a stage number (0 to 3) and a\n> colon, followed by a path; this names a blob object in the index\n> at the given path. Missing stage number (and the colon that\n> follows it) names an stage 0 entry.\n\nYou can see that at best when you have a conflicted merge. For example, if \n\"git ls-files --unmerged\" says that \"README\" is unmerged, \"git show \n:1:README\" will show _your_ original version, while \"git show :2:README\" \nwill show the to-be-merged version.\n\nHth,\nDscho\n"},{"id":"40754","messageId":"7vejm1d370.fsf@assigned-by-dhcp.cox.net","threadId":"7906","inReplyTo":"alpine.LFD.0.98.0704301138320.3419@woody.linux-foundation.org","subject":"Re: git-rev-parse(1) questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-30T20:20:35Z","receivedAt":"2007-04-30T20:20:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 30 Apr 2007, Jari Aalto wrote:\n>> ...\n>> * A colon, optionally followed by a stage number (0 to 3) and a\n>> colon, followed by a path; this names a blob object in the index\n>> at the given path. Missing stage number (and the colon that\n>> follows it) names an stage 0 entry.\n>\n> You'd never use this unless you're working with a unmerged tree entry, and \n> then you can use it for things like\n>\n> \tgit diff :1:my-path :2:their-path\n>\n> if you want to look at the differences between the two blobs that are \n> unmerged, and come from different branches (\":1:my-path\" comes from the \n> branch you were merging things into,and the \":2:their-path\" comes from the \n> branch you were merging from).\n>\n> That can be useful in the extremely rare case...\n\nA small correction. :1:path comes from the common ancestor,\n:2:mine comes from the branch you are on and merging into, and\n:3:theirs is what the other branch you were merging from has.\n\nPeople can see how rarely this is used interactively; even\noriginal authors of git can get it wrong ;-).\n"}]}