{"thread":{"id":"1206","subject":"How to get a directory filled with v2.6.11?","startedAt":"2005-07-12T05:03:47Z","lastAt":"2005-07-13T20:46:32Z","messageCount":5,"participants":["Marc Singer","Matthias Urlichs","Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6016","messageId":"20050712050347.GA10751@buici.com","threadId":"1206","inReplyTo":null,"subject":"How to get a directory filled with v2.6.11?","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-12T05:03:47Z","receivedAt":"2005-07-12T05:03:47Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"I switched to using the git version in source control.\nCheckout/branching works great. :-)\n\nBut, this version of git doesn't let me do\n\n # git checkout -f v2.6.11\n error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit\n Needed a single revision\n\nwhich I suspect is protection added to prevent my special sort of\nshenanigans. If I cannot perform the checkout anymore, is there\nanother way to fill a directory with the contents of that particular\ntree?\n\nWhat am I doing? I've got some updates against 2.6.11 orphaned in\nanother develpment directory. I could just upack a tar.bz2 file for\n2.6.11, but git is more clever. I want to perform a diff against the\ntagged v2.6.11 and my development tree.\n"},{"id":"6020","messageId":"pan.2005.07.12.06.18.44.195557@smurf.noris.de","threadId":"1206","inReplyTo":"20050712050347.GA10751@buici.com","subject":"Re: How to get a directory filled with v2.6.11?","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-12T06:18:45Z","receivedAt":"2005-07-12T06:18:45Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Marc Singer wrote:\n\n> v2.6.11, 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c\n\nYou can create your own parent-less commit for that tree.\n(It's what I did...)\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\n\"It was the most earnest ambition I ever had....Not that I ever\n really wanted to be a preacher, but because it never occurred to\n me that a preacher could be damned. It looked like a safe job.\"\n [Mark Twain, a Biography]\n"},{"id":"6066","messageId":"Pine.LNX.4.58.0507122116280.17536@g5.osdl.org","threadId":"1206","inReplyTo":"20050712050347.GA10751@buici.com","subject":"Re: How to get a directory filled with v2.6.11?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-13T04:37:06Z","receivedAt":"2005-07-13T04:37:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Marc Singer wrote:\n>\n> I switched to using the git version in source control.\n> Checkout/branching works great. :-)\n> \n> But, this version of git doesn't let me do\n> \n> # git checkout -f v2.6.11\n> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit\n> Needed a single revision\n> \n> which I suspect is protection added to prevent my special sort of\n> shenanigans. If I cannot perform the checkout anymore, is there\n> another way to fill a directory with the contents of that particular\n> tree?\n\nYes. Multiple ways. \n\nYou can\n\n - just force that tree to be checked out:\n\n\tgit-read-tree -m v2.6.11\n\tgit-checkout-cache -f -u -a\n\n this basically gets you the state at the time of v2.6.11, but you still \n don't have a _commit_ yet, so you'd have nothing to start actual \n development from. BE CAREFUL! Your \"HEAD\" is now pointing to something \n else than what you have checked out, so the next thing you want to do \n is fix that up.\n\n - now, you can commit that as a _parentless_ commit (ie an \"Initial\n commit\") on a new branch, with something like this:\n\n\techo \"Linux 2.6.11\" | git-commit-tree $(git-write-tree) > .git/refs/heads/my-branch\n\tln -sf .git/HEAD refs/heads/my-branch\n\n and off you go. The above just creates a commit of the tree (which is \n the v2.6.11 tree, since you did a \"git-read-tree\" on it), and uses the\n commit message \"Linux 2.6.11\"). It gives it no parents, and writes the\n result to the \"my-branch\" thing. It then makes HEAD point to that \n branch, which completes the thing, and now your tree is in a consistent \n state (ie HEAD matches what you have checked out, which matches \n v2.6.11)\n\nThat's one way.\n\nYou can do it sneakier too, if you want to, and create the branch first. \nIn particular, you can do\n\n\tgit-cat-file tag v2.6.11\n\nwhich will print out that tag, which starts with:\n\n\tobject c39ae07f393806ccf406ef966e9a15afc43cc36a\n\ttype tree\n\ttag v2.6.11-tree\n\t...\n\nand now you can just do use that tree directly, without even reading it \nin:\n\n\thead=$(echo \"Linux 2.6.11\" | git-commit-tree c39ae07f393806ccf406ef966e9a15afc43cc36a)\n\techo $head > .git/refs/heads/my-branch\n\nwhich will give you the new branch.\n\nNow you can just do\n\n\tgit checkout my-branch\n\nand you'll be there.\n\nThat said, whatever you do you will eventually end up with a series of\ncommits that are not related to the \"normal\" commits in the 2.6.12-rc2+\nchain, and since they don't have a common point, git won't be able to\nmerge them for you. Git will be able to _track_ them for you, but at some\npoint you'll want to probably try to move them forward to the \"rest\" of\nthe git history.\n\nAnd I'll warn you that that is not going to be entirely trivial, although\nJunio's \"cherrypick\" scripts should be useful as a way to automate it at\nleast to some degree. This is why it would be so much easier if you could \nhave started with a 2.6.12-rc2 or other \"real\" commit ;)\n\n\t\t\tLinus\n"},{"id":"6088","messageId":"7vvf3ewig0.fsf@assigned-by-dhcp.cox.net","threadId":"1206","inReplyTo":"Pine.LNX.4.58.0507122116280.17536@g5.osdl.org","subject":"Re: How to get a directory filled with v2.6.11?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-13T20:37:51Z","receivedAt":"2005-07-13T20:37:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That said, whatever you do you will eventually end up with a series of\n> commits that are not related to the \"normal\" commits in the 2.6.12-rc2+\n> chain, and since they don't have a common point, git won't be able to\n> merge them for you. Git will be able to _track_ them for you, but at some\n> point you'll want to probably try to move them forward to the \"rest\" of\n> the git history.\n>\n> And I'll warn you that that is not going to be entirely trivial, although\n> Junio's \"cherrypick\" scripts should be useful as a way to automate it at\n> least to some degree. This is why it would be so much easier if you could \n> have started with a 2.6.12-rc2 or other \"real\" commit ;)\n\nI do not think git-cherry would be that useful in this context.\nNobody upstream is merging things into your development trail,\nstarted at the private commit you made based on the 2.6.11 tree.\n\nI was wondering if adding \"graft trail\" to merge-base command\nwould help this situation.\n\n SYNOPSIS\n --------\n 'git-merge-base' ( --graft )* \n\n ...\n\n OPTIONS\n -------\n ::\n The two heads being merged.\n\n --graft ::\n Treat as if is one of the ancestors of\n when computing the commit ancestry chain.\n Can be specified more than once.\n\nThen we could say \"--graft v2.6.11 v2.6.12-rc2\".\n\nWe may want to have a configuration file in .git/ directory (I\nthink it belongs to .git/objects/ hierarchy, because this is not\nper work-tree thing but per project thing) that record this\n\"graft\" relationship.\n\nWhen we have not-so-stupid [*1*] merge algorithm in place, we\ncould do even better. Starting from v2.6.11 tree, we can\nrebuild (from BKCVS) the development trail up to v2.6.12-rc2,\nwhich is independent from the current kernel development trail\nwhich started at (a different) v2.6.12-rc2. Use the former one\nas , and the latter one as , and the \"clever\"\nmerge algorithm would be able to follow across the v2.6.12-rc2\ndiscontiguity and trace the development back to v2.6.11.\n\n[Footnote]\n\n*1* \n\nSo if you want to document that the current automatic merge is stupid,\nhey, go wild. It _is_ stupid. It's surprisingly effective, but that may be\nbecause of kernel development patterns and may not be true in other\nprojects.\n"},{"id":"6092","messageId":"Pine.LNX.4.58.0507131342190.17536@g5.osdl.org","threadId":"1206","inReplyTo":"7vvf3ewig0.fsf@assigned-by-dhcp.cox.net","subject":"Re: How to get a directory filled with v2.6.11?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-13T20:46:32Z","receivedAt":"2005-07-13T20:46:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 13 Jul 2005, Junio C Hamano wrote:\n> \n> I do not think git-cherry would be that useful in this context.\n> Nobody upstream is merging things into your development trail,\n> started at the private commit you made based on the 2.6.11 tree.\n\nNo, the point being that he (or anybody else) could move the commits as\npatches, one by one, from his 2.6.11 base to whatever later base that _is_\nin the commit history.\n\nIt's really the same issue as with cherry-picking: you do commits one at a\ntime as diffs, see if that diff already exists in the destination stream,\nand if not, you try to apply it as a patch and re-commit it with the old\ncommit message in a new place in history.\n\n\t\t\tLinus\n"}]}