{"thread":{"id":"2175","subject":"How to create a new branch based on a tag?","startedAt":"2005-10-21T03:37:32Z","lastAt":"2005-10-21T19:14:16Z","messageCount":8,"participants":["Ben Lau","Martin Langhoff","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10404","messageId":"46a038f90510202037l7dd40271qcc0634295e092068@mail.gmail.com","threadId":"2175","inReplyTo":"435901F7.9020509@ust.hk","subject":"Re: How to create a new branch based on a tag?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-21T03:37:32Z","receivedAt":"2005-10-21T03:37:32Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/22/05, Ben Lau wrote:\n> Hi,\n>\n> I would like to create a branch of my own work based on a specific\n> kernel version(i.e\n> v2.6.11). I tried with:\n>\n> > git-branch my2.6.11 v2.6.11\n> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a\n> commit\n> fatal: Needed a single revision\n\nWhat you're after is\n\n git-rev-parse --verify ^0 > .refs/heads/mynewbranch\n\n\"branches\" are very lightweight -- it's a ref containing the SHA1 of\nthe commit you want it to be at. So if you find the SHA1 of the commit\nin gitk or wherever, just\n\n echo SHA1 > .refs/heads/mynewbranch\n\nand you're sorted. Do git-checkout to switch to it.\n\ncheers,\n\n\nmartin\n"},{"id":"10405","messageId":"7vsluv5y0p.fsf@assigned-by-dhcp.cox.net","threadId":"2175","inReplyTo":"435901F7.9020509@ust.hk","subject":"Re: How to create a new branch based on a tag?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-21T03:50:30Z","receivedAt":"2005-10-21T03:50:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ben Lau writes:\n\n> As v2.6.11 is a tree object(tag), git-checkout and git-branch could \n> not process it. The\n> only way I know is using git-read-tree to fetch v2.6.11 content into \n> current index and start\n> a branch based on it. Is there any simpler method?\n\nThe way you know is as good as it gets. v2.6.11-tree case is\nreally an unfortunate special case.\n"},{"id":"10412","messageId":"7vzmp3319v.fsf@assigned-by-dhcp.cox.net","threadId":"2175","inReplyTo":"4359161B.5000808@ust.hk","subject":"Re: How to create a new branch based on a tag?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-21T05:08:28Z","receivedAt":"2005-10-21T05:08:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ben Lau writes:\n\n>>The way you know is as good as it gets. v2.6.11-tree case is\n>>really an unfortunate special case.\n>>\n> What is wrong with the v2.6.11-tree? I just thought it is a duplicate tag\n> of v2.6.11.\n\nThey are not *wrong* per-se. They are tags to tree objects\nwithout any associated commit history -- that makes them\ninappropriate to be used as branch heads.\n\nLinus or somebody authoritative could do:\n\n $ commit=$(echo v2.6.11 | \\\n git-commit-tree c39ae07f393806ccf406ef966e9a15afc43cc36a)\n $ git-tag -s -m 'v2.6.11 canonical \"fake\" commit' v2.6.11fake $commit\n\nand tell everybody interested to have:\n\n1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 xxxxxxxxxx\n\n(where xxxxx... is the value of $commit above) in their\ninfo/grafts file. Then we *could* pretend that v2.6.12-rc2's\nparent is v2.6.11. You could branch off from v2.6.11fake commit\nand base your development, and later you could merge that into\nlater development history (say, v2.6.14-rc5) if you wanted to.\n\nIf Linus does something like the above, the graft probably be\nbetter done between the current v2.6.12-rc2 based commit history\nand the corresponding commit in the history resurrected from\nBKCVS (torvalds/old-2.6-bkcvs.git). Then you could even base\nyour development on top of v2.4.0 ;-).\n\nFunnily, v2.6.12-rc2 commit in the current history and BKCVS\nv2.6.12-rc2 commit in the resurrected history have different\ntree IDs.\n\nI am however not quite sure how useful the above would be,\nthough. EVen between 2.6.11 and 2.6.12-rc2 much have happened,\nso unless the changes you are making apply to the part that did\nnot change between those two, merge conflict resolution might be\nquite a chore.\n"},{"id":"10418","messageId":"7v4q7bz3f9.fsf@assigned-by-dhcp.cox.net","threadId":"2175","inReplyTo":"43593E08.1060208@ust.hk","subject":"Re: How to create a new branch based on a tag?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-21T08:20:58Z","receivedAt":"2005-10-21T08:20:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ben Lau writes:\n\n>>Linus or somebody authoritative could do:\n>>\n>> $ commit=$(echo v2.6.11 | \\\n>> git-commit-tree c39ae07f393806ccf406ef966e9a15afc43cc36a)\n>> $ git-tag -s -m 'v2.6.11 canonical \"fake\" commit' v2.6.11fake $commit\n>>\n>>and tell everybody interested to have:\n>>\n>>1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 xxxxxxxxxx\n>>\n>>(where xxxxx... is the value of $commit above) in their\n>>info/grafts file. Then we *could* pretend that v2.6.12-rc2's\n>>parent is v2.6.11. You could branch off from v2.6.11fake commit\n>>and base your development, and later you could merge that into\n>>later development history (say, v2.6.14-rc5) if you wanted to.\n>>\n> Thanks for detail explanation.\n>\n> It is a little bit difficult for me. The result of `git log`\n> shows that the eldest commit is 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\n> which is linux-2.6.12-rc2. Is that means the git repository do not\n> store the history before this tag?\n\nLinux development on git, at least the history available\nofficially, starts from 2.6.12-rc2.\n\nLet's try to find things together. In the typescript below,\n\": siamese;\" is my shell prompt $PS1.\n\nFirst, look at v2.6.12-rc2 object. What type is it?\n\n : siamese; git-cat-file -t v2.6.12-rc2\n tag\n\nIt is a tag. Let's see what's inside.\n\n : siamese; git-cat-file tag v2.6.12-rc2\n object 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\n type commit\n tag v2.6.12-rc2\n\n Linux v2.6.12-rc2 release\n -----BEGIN PGP SIGNATURE-----\n Version: GnuPG v1.2.4 (GNU/Linux)\n\n iD8DBQBCbW8ZF3YsRnbiHLsRAgFRAKCq/TkuDaEombFABkPqYgGCgWN2lQCcC0qc\n wznDbFU45A54dZC8RZ5JxyE=\n =ESRP\n -----END PGP SIGNATURE-----\n\nOK, that points at a commit and object name is 1da177e4c...\nLet's look at that object. You can abbreviate object name here.\n\n : siamese; git-cat-file commit 1da177e4c\n tree 0bba044c4ce775e45a88a51686b5d9f90697ea9d\n author Linus Torvalds 1113690036 -0700\n committer Linus Torvalds 1113690036 -0700\n\n Linux-2.6.12-rc2\n\n Initial git repository build. I'm not bothering with the full history,\n even though we have it. We can create a separate \"historical\" git\n archive of that later if we want to, and in the meantime it's about\n 3.2GB when imported into git - space that would just make the early\n git days unnecessarily complicated, when we don't have a lot of good\n infrastructure for it.\n\n Let it rip!\n\nNotice the top three lines? There is no \"parent \" line, like\nrecent commits, for example:\n\n : siamese; git-cat-file commit v2.6.13\n tree 9b182c47688d261775f8c49e06cb795dfc8931dc\n parent 20b1730af3ae05450b0e03f5aed40c4313f65db6\n author Linus Torvalds 1125272461 -0700\n committer Linus Torvalds 1125272461 -0700\n\n Linux v2.6.13\n\nWhat this means is that 2.6.12-rc2 was the big-bang, the\nbeginning of time, as far as the history recorded in git is\nconcerned. There was nothing before that time. On the other\nhand, v2.6.13 has a \"parent \" line -- this names another commit,\nand Linus has some change between that parent commit and\nv2.6.13.\n\n : siamese; git diff v2.6.13^ v2.6.13\n diff --git a/Makefile b/Makefile\n index 300f61f..5acd1fc 100644\n --- a/Makefile\n +++ b/Makefile\n @@ -1,7 +1,7 @@\n VERSION = 2\n PATCHLEVEL = 6\n SUBLEVEL = 13\n -EXTRAVERSION =-rc7\n +EXTRAVERSION =\n NAME=Woozy Numbat\n\n # *DOCUMENTATION*\n\nOf course, the version number has changed. v2.6.13^ is a\nshort-hand to say \"first parent of v2.6.13\" (see git-rev-parse\ndocumentation).\n\n> Then how can `git-read-tree v2.6.11` fetchs the content of\n> v2.6.11?\n\nTrees do not have their position in timeline. Only commits do.\nThis is explained by King Penguin himself. If you are reading\nthe documentation on the web,\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/\n\nfind the link \"The [Discussion] section below contains much\nuseful information...\", and follow it. README in the git source\ntree at the top level has the same. The description there\ncovers the object database and blob/tree/commit/tag objects, and\nhow these things fit together.\n\nThink of a tree as if you created a tar archive (but without\neven timestamps) of an extracted kernel source tree. It is a\nsnapshot of directory structure and file contents. You can have\nmany such snapshots, but they themselves do not describe how\neach of them is related with other snapshots. Commit objects\ntie them together and give them their position in time. The\n\"parent \" line above refers to another commit (note that you can\nhave more than one \"parent \" lines to denote a merge).\n\n> By the way, How could you find the \n> c39ae07f393806ccf406ef966e9a15afc43cc36a out?\n\n : siamese; git-cat-file tag v2.6.11-tree\n object c39ae07f393806ccf406ef966e9a15afc43cc36a\n type tree\n tag v2.6.11-tree\n\n This is the 2.6.11 tree object.\n\n NOTE! There's no commit for this, since it happened before I started with git.\n Eventually we'll import some sort of history, and that should tie this tree\n object up to a real commit. In the meantime, this acts as an anchor point for\n doing diffs etc under git.\n -----BEGIN PGP SIGNATURE-----\n Version: GnuPG v1.2.4 (GNU/Linux)\n\n iD8DBQBCeV/eF3YsRnbiHLsRAl+SAKCVp8lVXwpUhMEvy8N5jVBd16UCmACeOtP6\n KLMHist5yj0sw1E4hDTyQa0=\n =/bIK\n -----END PGP SIGNATURE-----\n\nWhen v2.6.11 was released, there was no git. Linus can create a\ntree out of that release, and that is what he did.\n\nHe could have created a commit that claimed it was the beginning\nof time. He did not do that because what he could not do was to\nretroactively make that commit a parent of the v2.6.12-rc2\ncommit he already made.\n\nThis is because any git object (any type) has a name based on a\ncryptographically secure hash of its contents, and \"the\ncontents\" in the case of a commit object includes those header\nlines (which tree object that commit records, what commits its\nparents are, who wrote it and who committed it when).\n\nRetroactively adding/modifying parent to an existing commit\nwould mean you would change its contents -- hence its name. An\nexisting child of that commit now needs to get its \"parent \"\nline changed to point at the updated parent. Which means\nrewriting the whole history since v2.6.12-rc2 commit.\n\nThe \"graft\" facility I mentioned in my previous message was\ninvented much later. It lets you pretend that a given commit\nobject has an arbitrary set of commit objects as its parents,\nwhich is typically different from its real parents. By using\nit, you *could* pretend that v2.6.12-rc2 is a child of\nv2.6.11fake commit (which you create by wrapping the v2.6.11\ntree into it).\n\nThere is a mention on \"graft\" facility in the repository layout\ndocumentation:\n\nhttp://www.kernel.org/pub/software/scm/git/docs/repository-layout.html\n\nwe might want to also refer to this from git-log documentation, \nand perhaps git-merge-base documentation.\n"},{"id":"10400","messageId":"435901F7.9020509@ust.hk","threadId":"2175","inReplyTo":null,"subject":"How to create a new branch based on a tag?","fromName":"Ben Lau","fromEmail":"benlau@ust.hk","sentAt":"2005-10-21T14:57:59Z","receivedAt":"2005-10-21T14:57:59Z","isPatch":false,"sender":{"key":"benlau@ust.hk","avatar":null},"body":"Hi,\n\n I would like to create a branch of my own work based on a specific \nkernel version(i.e\nv2.6.11). I tried with:\n\n > git-branch my2.6.11 v2.6.11\nerror: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a \ncommit\nfatal: Needed a single revision\n\n As v2.6.11 is a tree object(tag), git-checkout and git-branch could \nnot process it. The\nonly way I know is using git-read-tree to fetch v2.6.11 content into \ncurrent index and start\na branch based on it. Is there any simpler method?\n\nThanks!\n"},{"id":"10408","messageId":"43591421.9030400@ust.hk","threadId":"2175","inReplyTo":"46a038f90510202037l7dd40271qcc0634295e092068@mail.gmail.com","subject":"Re: How to create a new branch based on a tag?","fromName":"Ben Lau","fromEmail":"benlau@ust.hk","sentAt":"2005-10-21T16:15:29Z","receivedAt":"2005-10-21T16:15:29Z","isPatch":false,"sender":{"key":"benlau@ust.hk","avatar":null},"body":"Martin Langhoff wrote:\n\n>On 10/22/05, Ben Lau wrote:\n> \n>\n>>Hi,\n>>\n>> I would like to create a branch of my own work based on a specific\n>>kernel version(i.e\n>>v2.6.11). I tried with:\n>>\n>> > git-branch my2.6.11 v2.6.11\n>>error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a\n>>commit\n>>fatal: Needed a single revision\n>> \n>>\n>\n>What you're after is\n>\n> git-rev-parse --verify ^0 > .refs/heads/mynewbranch\n>\n>\"branches\" are very lightweight -- it's a ref containing the SHA1 of\n>the commit you want it to be at. So if you find the SHA1 of the commit\n>in gitk or wherever, just\n>\n> echo SHA1 > .refs/heads/mynewbranch\n>\n>and you're sorted. Do git-checkout to switch to it.\n>\n>cheers,\n>\n>\n>martin\n> \n>\nThe command complains:\n\n >git-rev-parse --verify v2.6.11^\n error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not \na commit\n fatal: Needed a single revision\n\nI think it need another way to convert a tag/tree object into a commit ?\n"},{"id":"10410","messageId":"4359161B.5000808@ust.hk","threadId":"2175","inReplyTo":"7vsluv5y0p.fsf@assigned-by-dhcp.cox.net","subject":"Re: How to create a new branch based on a tag?","fromName":"Ben Lau","fromEmail":"benlau@ust.hk","sentAt":"2005-10-21T16:23:55Z","receivedAt":"2005-10-21T16:23:55Z","isPatch":false,"sender":{"key":"benlau@ust.hk","avatar":null},"body":"Junio C Hamano wrote:\n\n>Ben Lau writes:\n>\n> \n>\n>>As v2.6.11 is a tree object(tag), git-checkout and git-branch could \n>>not process it. The\n>>only way I know is using git-read-tree to fetch v2.6.11 content into \n>>current index and start\n>>a branch based on it. Is there any simpler method?\n>> \n>>\n>\n>The way you know is as good as it gets. v2.6.11-tree case is\n>really an unfortunate special case.\n>\n> \n>\nWhat is wrong with the v2.6.11-tree? I just thought it is a duplicate tag\nof v2.6.11.\n"},{"id":"10417","messageId":"43593E08.1060208@ust.hk","threadId":"2175","inReplyTo":"7vzmp3319v.fsf@assigned-by-dhcp.cox.net","subject":"Re: How to create a new branch based on a tag?","fromName":"Ben Lau","fromEmail":"benlau@ust.hk","sentAt":"2005-10-21T19:14:16Z","receivedAt":"2005-10-21T19:14:16Z","isPatch":false,"sender":{"key":"benlau@ust.hk","avatar":null},"body":"Junio C Hamano wrote:\n\n>Ben Lau writes:\n>\n> \n>\n>>>The way you know is as good as it gets. v2.6.11-tree case is\n>>>really an unfortunate special case.\n>>>\n>>> \n>>>\n>>What is wrong with the v2.6.11-tree? I just thought it is a duplicate tag\n>>of v2.6.11.\n>> \n>>\n>\n>They are not *wrong* per-se. They are tags to tree objects\n>without any associated commit history -- that makes them\n>inappropriate to be used as branch heads.\n>\n>Linus or somebody authoritative could do:\n>\n> $ commit=$(echo v2.6.11 | \\\n> git-commit-tree c39ae07f393806ccf406ef966e9a15afc43cc36a)\n> $ git-tag -s -m 'v2.6.11 canonical \"fake\" commit' v2.6.11fake $commit\n>\n>and tell everybody interested to have:\n>\n>1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 xxxxxxxxxx\n>\n>(where xxxxx... is the value of $commit above) in their\n>info/grafts file. Then we *could* pretend that v2.6.12-rc2's\n>parent is v2.6.11. You could branch off from v2.6.11fake commit\n>and base your development, and later you could merge that into\n>later development history (say, v2.6.14-rc5) if you wanted to.\n>\n>If Linus does something like the above, the graft probably be\n>better done between the current v2.6.12-rc2 based commit history\n>and the corresponding commit in the history resurrected from\n>BKCVS (torvalds/old-2.6-bkcvs.git). Then you could even base\n>your development on top of v2.4.0 ;-).\n>\n>Funnily, v2.6.12-rc2 commit in the current history and BKCVS\n>v2.6.12-rc2 commit in the resurrected history have different\n>tree IDs.\n>\n>I am however not quite sure how useful the above would be,\n>though. EVen between 2.6.11 and 2.6.12-rc2 much have happened,\n>so unless the changes you are making apply to the part that did\n>not change between those two, merge conflict resolution might be\n>quite a chore.\n>\n>\n>-\n>To unsubscribe from this list: send the line \"unsubscribe git\" in\n>the body of a message to majordomo@vger.kernel.org\n>More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n>\nThanks for detail explanation.\n\nIt is a little bit difficult for me. The result of `git log`\nshows that the eldest commit is 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\nwhich is linux-2.6.12-rc2. Is that means the git repository do not\nstore the history before this tag? Then how can `git-read-tree\nv2.6.11` fetchs the content of v2.6.11?\n\nBy the way, How could you find the \nc39ae07f393806ccf406ef966e9a15afc43cc36a out?\n\nI have followed your instuctions and now have my own 2.6.11 \nbranch(my2.6.11). Should be fine\nnow. Many thanks to all you guys.\n"}]}