{"thread":{"id":"23926","subject":"git fast-export/fast-import *facepalm*","startedAt":"2010-05-27T20:46:38Z","lastAt":"2010-05-27T23:03:02Z","messageCount":8,"participants":["Chris Packham","Shawn O. Pearce","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"142466","messageId":"AANLkTinV5mEACphA-nW9URce0Mh9xyu3UjWmfBqL6cLN@mail.gmail.com","threadId":"23926","inReplyTo":null,"subject":"git fast-export/fast-import *facepalm*","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-05-27T20:46:38Z","receivedAt":"2010-05-27T20:46:38Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi,\n\nI've had a bit of a brain melt and have done something silly with git\nfast-import and was hoping someone would be able to get me out of the\nmess I've created.\n\nBasically I've got a linux repository which for various reasons isn't\nbased of any of the kernel.org ones but reflects our kernel\ndevelopment on top of vanilla kernel tarballs. When we update we take\nthe tarball and extract and commit it to a vendor branch then merge\nthat with our main. A little strange but it works for us (despite\nhaving to go hunting on kernel.org when we want the external history).\n\nMy brain melt came when I wanted to get the set of changes between 2\nversions from a public branch and import them into our repository.\nHaving just learned about git fast-export I decided that it was the\nright tool for the job so I did the following\n\n(cd linux-2.6.32.y; git fast-export v2.6.32.12..v2.6.32.14) | git fast-import\n\nWhat I've ended up with is a repository with a detached set of changes i.e\n\no -o   l - l - l - l - l - l     o - master\n     \\                          /\n      o - o - o - o - o - o\n\no = our commits\nl = linux commits\n\nBecause the code is common textually I think what I really should have done is\n\n(cd linux-2.6.32.y; git format-patch v2.6.32.12..v2.6.32.14) | git am\n\nWhich I'll give a try in a minute. In the meantime is there anyway for\nme to safely remove the upstream linux commits without loosing our\ncommits in the process?\n\nThanks,\nChris\n"},{"id":"142467","messageId":"20100527210328.GN16470@spearce.org","threadId":"23926","inReplyTo":"AANLkTinV5mEACphA-nW9URce0Mh9xyu3UjWmfBqL6cLN@mail.gmail.com","subject":"Re: git fast-export/fast-import *facepalm*","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-05-27T21:03:28Z","receivedAt":"2010-05-27T21:03:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Chris Packham <judge.packham@gmail.com> wrote:\n> What I've ended up with is a repository with a detached set of changes i.e\n> \n> o -o   l - l - l - l - l - l     o - master\n>      \\                          /\n>       o - o - o - o - o - o\n> \n> o = our commits\n> l = linux commits\n> \n> Because the code is common textually I think what I really should have done is\n> \n> (cd linux-2.6.32.y; git format-patch v2.6.32.12..v2.6.32.14) | git am\n> \n> Which I'll give a try in a minute. In the meantime is there anyway for\n> me to safely remove the upstream linux commits without loosing our\n> commits in the process?\n\nIf I read your diagram right, the l-l-l chain isn't connected at\nall to your graph, so it should just get removed with `git gc`.\n\nBut if it is connected due to a merge with your master, lookup the\nmerge and find its parent which is your local stuff and `git reset\n--hard` to that commit.\n\n-- \nShawn.\n"},{"id":"142469","messageId":"AANLkTimgh-1u9_p9SzB6DlP_gPDBiPJZkg-Hjvpq0eCM@mail.gmail.com","threadId":"23926","inReplyTo":"AANLkTinV5mEACphA-nW9URce0Mh9xyu3UjWmfBqL6cLN@mail.gmail.com","subject":"Re: git fast-export/fast-import *facepalm*","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-27T21:19:58Z","receivedAt":"2010-05-27T21:19:58Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, May 27, 2010 at 4:46 PM, Chris Packham <judge.packham@gmail.com> wrote:\n> My brain melt came when I wanted to get the set of changes between 2\n> versions from a public branch and import them into our repository.\n> Having just learned about git fast-export I decided that it was the\n> right tool for the job so I did the following\n>\n> (cd linux-2.6.32.y; git fast-export v2.6.32.12..v2.6.32.14) | git fast-import\n\nPersonally what I would do is use git rebase instead:\n\n# WARNING: untested.  back up your repo first!\ncd my-repo\ngit fetch ../linux-2.6.32.y v2.6.32.14\ngit branch b FETCH_HEAD\ngit fetch ../linux-2.6.32.y v2.6.32.12\ngit branch a FETCH_HEAD\ngit checkout b\ngit rebase --onto master a\n# now your branch b should be master + the patches from a..b\n\n> Which I'll give a try in a minute. In the meantime is there anyway for\n> me to safely remove the upstream linux commits without loosing our\n> commits in the process?\n\nLooks like Shawn answered this question.  In any case, the answer is git-reset.\n\nHave fun,\n\nAvery\n"},{"id":"142470","messageId":"AANLkTik9QxiAjZHigx0YS5ybZwj6U7l0fK-byUmBirnO@mail.gmail.com","threadId":"23926","inReplyTo":"20100527210328.GN16470@spearce.org","subject":"Re: git fast-export/fast-import *facepalm*","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-05-27T21:57:06Z","receivedAt":"2010-05-27T21:57:06Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Thu, May 27, 2010 at 2:03 PM, Shawn O. Pearce <spearce@spearce.org> wrote:\n> Chris Packham <judge.packham@gmail.com> wrote:\n>> What I've ended up with is a repository with a detached set of changes i.e\n>>\n>> o -o   l - l - l - l - l - l     o - master\n>>      \\                          /\n>>       o - o - o - o - o - o\n>>\n>> o = our commits\n>> l = linux commits\n>>\n>> Because the code is common textually I think what I really should have done is\n>>\n>> (cd linux-2.6.32.y; git format-patch v2.6.32.12..v2.6.32.14) | git am\n>>\n>> Which I'll give a try in a minute. In the meantime is there anyway for\n>> me to safely remove the upstream linux commits without loosing our\n>> commits in the process?\n>\n> If I read your diagram right, the l-l-l chain isn't connected at\n> all to your graph, so it should just get removed with `git gc`.\n>\n\nWell it _looks_ detached in gitk I can't see any merge commits. I've\ntried git gc but no joy. Maybe I need to tell it to be a bit more\nthorough.\n\n> But if it is connected due to a merge with your master, lookup the\n> merge and find its parent which is your local stuff and `git reset\n> --hard` to that commit.\n>\n> --\n> Shawn.\n>\n"},{"id":"142471","messageId":"AANLkTinrUWtqx34U3-FFnyAXXYFkQiwrXc6USXJYR2xE@mail.gmail.com","threadId":"23926","inReplyTo":"AANLkTik9QxiAjZHigx0YS5ybZwj6U7l0fK-byUmBirnO@mail.gmail.com","subject":"Re: git fast-export/fast-import *facepalm*","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-27T22:01:39Z","receivedAt":"2010-05-27T22:01:39Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, May 27, 2010 at 5:57 PM, Chris Packham <judge.packham@gmail.com> wrote:\n> Well it _looks_ detached in gitk I can't see any merge commits. I've\n> tried git gc but no joy. Maybe I need to tell it to be a bit more\n> thorough.\n\nWhy is it showing up in gitk at all?  Does it have its own branch\nname?  gitk will normally only show commits that are attached to\nsomething, unless you list a particular commit id explicitly on its\ncommand line.\n\nOnce the commits are \"detached\" correctly, saving the disk space is\nkind of unnecessary.  (Most likely the old commits are being held in\nthe reflog at least, which usually expires in 30 days or so for\nsafety.)  Moreover, most of the space is probabably space occupied by\nthe actual files in the revisions, which will be needed when you port\nthe patches \"correctly\" anyhow, so there's no point in going through\nextra effort to recover the space just so you can use it again.\n\nHave fun,\n\nAvery\n"},{"id":"142472","messageId":"AANLkTimQWW3WLqa0vWmKTYKsbVvnZiStEJI0N9N5tfng@mail.gmail.com","threadId":"23926","inReplyTo":"AANLkTinJd1hZE6LiJRHWYknS7e2YUHtKApTaKfpPPfKJ@mail.gmail.com","subject":"Re: git fast-export/fast-import *facepalm*","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-05-27T22:18:57Z","receivedAt":"2010-05-27T22:18:57Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Thu, May 27, 2010 at 3:11 PM, Avery Pennarun <apenwarr@gmail.com> wrote:\n> On Thu, May 27, 2010 at 6:06 PM, Chris Packham <judge.packham@gmail.com> wrote:\n>> They're showing up with 'gitk --all'. I've made a backup so I can\n>> expire the reflog and see if they go away.\n>\n> gitk --all shouldn't be showing stuff just because it's in the reflog.\n>  Does it have a branchname tag next to it?  Have you exit/restarted\n> gitk or are you just using its refresh button?  The latter doesn't\n> work very well across branch deletion.\n>\n> Avery\n>\n\nThe commits do have tags. I'll try deleting them and gc'ing again.\n"},{"id":"142474","messageId":"AANLkTiksU3sswdSlQJNqlyd1AK4dvRoftLhrghELq8j5@mail.gmail.com","threadId":"23926","inReplyTo":"AANLkTimQWW3WLqa0vWmKTYKsbVvnZiStEJI0N9N5tfng@mail.gmail.com","subject":"Re: git fast-export/fast-import *facepalm*","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-05-27T22:57:19Z","receivedAt":"2010-05-27T22:57:19Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Thu, May 27, 2010 at 3:18 PM, Chris Packham <judge.packham@gmail.com> wrote:\n> On Thu, May 27, 2010 at 3:11 PM, Avery Pennarun <apenwarr@gmail.com> wrote:\n>> On Thu, May 27, 2010 at 6:06 PM, Chris Packham <judge.packham@gmail.com> wrote:\n>>> They're showing up with 'gitk --all'. I've made a backup so I can\n>>> expire the reflog and see if they go away.\n>>\n>> gitk --all shouldn't be showing stuff just because it's in the reflog.\n>>  Does it have a branchname tag next to it?  Have you exit/restarted\n>> gitk or are you just using its refresh button?  The latter doesn't\n>> work very well across branch deletion.\n>>\n>> Avery\n>>\n>\n> The commits do have tags. I'll try deleting them and gc'ing again.\n>\n\nDeleting the tags seemed to do the trick as far as removing the\ndetached commits in gitk.\n\nNow git gc seems to be stuck\n\n~/linux> git --version\ngit version 1.7.1\n\n~/linux> git gc\nCounting objects: 20058 (went away made a coffee, came back still\nstuck at 20058)\n\nI've attached with gdb and have the following trace if its of any use\n(sorry I don't have debug symbols for libz). I've still got the\ndebugger attached if anyone wants me to dump out anything else.\n\n[Switching to Thread 0xb759e6c0 (LWP 7731)]\n0xb7898685 in ?? () from /lib/libz.so.1\n\n(gdb) bt\n#0  0xb7898685 in ?? () from /lib/libz.so.1\n#1  0xb7898f99 in ?? () from /lib/libz.so.1\n#2  0xb7895ccc in ?? () from /lib/libz.so.1\n#3  0xb7895ff8 in deflate () from /lib/libz.so.1\n#4  0x080f5ade in write_loose_object (sha1=<value optimized out>,\nhdr=<value optimized out>, hdrlen=<value optimized out>,\nbuf=0x8248570, len=1170, mtime=1274994118) at sha1_file.c:2314\n#5  0x080f6c09 in force_object_loose (sha1=0xb64ed204\n\"»²D\\v\\030\\005ªn\\fØÂ\\026\\201\\037EªÞãc{²JõØ`º\\214\\020IvæÐ`Æ0\\2113\\222ÿ»²R\\rdZ;#q\\f?\\001ü\\201#ZXr·»²U¯Jl²\\to\\022¬³\\004\\035\\215Õd0|z»²[çÝþaD2Ê\\206'ºL¾y\\037WÕi»²^©§Ê\\024H\\025\\003\\200\\006?\\003L=\\001¯?²dòäÒ\\223Úc\\234\\202\\224ÍfcpOì8?l\\0226\\021~óxTç¼y.iN¾¡\\036»²\\212·Y\\227\\211t\\v\\\"3\n\\200]\\\"®û\\227õ3»²¢\\024Té«>\\212.¡a@b'Ü[Ò=4\"..., mtime=1274994118) at\nsha1_file.c:2377\n#6  0x08089d8d in get_object_list (ac=<value optimized out>, av=<value\noptimized out>) at builtin/pack-objects.c:2050\n#7  0x0808c4e6 in cmd_pack_objects (argc=10, argv=0xbfb43118,\nprefix=0x0) at builtin/pack-objects.c:2317\n#8  0x0804b42b in handle_internal_command (argc=<value optimized out>,\nargv=<value optimized out>) at git.c:260\n#9  0x0804b5fe in main (argc=10, argv=0xbfb43118) at git.c:458\n"},{"id":"142475","messageId":"AANLkTinB3b8MOxz_8IN05bs2XKb3UyH0oDGNi-Pg2Kdg@mail.gmail.com","threadId":"23926","inReplyTo":"AANLkTiksU3sswdSlQJNqlyd1AK4dvRoftLhrghELq8j5@mail.gmail.com","subject":"Re: git fast-export/fast-import *facepalm*","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-05-27T23:03:02Z","receivedAt":"2010-05-27T23:03:02Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Thu, May 27, 2010 at 3:57 PM, Chris Packham <judge.packham@gmail.com> wrote:\n> On Thu, May 27, 2010 at 3:18 PM, Chris Packham <judge.packham@gmail.com> wrote:\n>> On Thu, May 27, 2010 at 3:11 PM, Avery Pennarun <apenwarr@gmail.com> wrote:\n>>> On Thu, May 27, 2010 at 6:06 PM, Chris Packham <judge.packham@gmail.com> wrote:\n>>>> They're showing up with 'gitk --all'. I've made a backup so I can\n>>>> expire the reflog and see if they go away.\n>>>\n>>> gitk --all shouldn't be showing stuff just because it's in the reflog.\n>>>  Does it have a branchname tag next to it?  Have you exit/restarted\n>>> gitk or are you just using its refresh button?  The latter doesn't\n>>> work very well across branch deletion.\n>>>\n>>> Avery\n>>>\n>>\n>> The commits do have tags. I'll try deleting them and gc'ing again.\n>>\n>\n> Deleting the tags seemed to do the trick as far as removing the\n> detached commits in gitk.\n>\n> Now git gc seems to be stuck\n>\n> ~/linux> git --version\n> git version 1.7.1\n>\n> ~/linux> git gc\n> Counting objects: 20058 (went away made a coffee, came back still\n> stuck at 20058)\n>\n> I've attached with gdb and have the following trace if its of any use\n> (sorry I don't have debug symbols for libz). I've still got the\n> debugger attached if anyone wants me to dump out anything else.\n>\n\nLooks like its come back now. I guess there was just one object that\nwas taking a while to pack.\n"}]}