{"thread":{"id":"7477","subject":"basics... when reading docs doesn't help","startedAt":"2007-03-29T20:50:51Z","lastAt":"2007-03-30T21:11:46Z","messageCount":18,"participants":["Guennadi Liakhovetski","J. Bruce Fields","Junio C Hamano","Matthieu Moy","Linus Torvalds","Theodore Tso","Andreas Herrmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"38349","messageId":"Pine.LNX.4.60.0703292225100.10351@poirot.grange","threadId":"7477","inReplyTo":null,"subject":"basics... when reading docs doesn't help","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2007-03-29T20:50:51Z","receivedAt":"2007-03-29T20:50:51Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"Hi all\n\nSince it's a basic question, I couldn't search archives - cannot come up \nwith good enough search keywords, but would be greatful for pointers.\n\nI've been using CVS for a few years now, briefly tried a couple of other \nCMS, but only briefly. Now trying to get to grisps with the git... And \njust cannot understand how everybody does it.\n\nThe package I'm trying to handle with git is the Linux kernel.\n\n1. Ok, I clone a repository from Linus or some else.\n\n2. as my internet connection is not very fast, although I do have \nflatrate, I prefer keeping a virgin cloned copy somewhere, where I only do \npulls from the original clone source, no edits.\n\n3. then I do git clone \n\n4. create a new branch in \n\n5. go hack / compile in the \n\n6. then I decide to build practically the same kernel for another machine, \ni.e., another configuration, maybe a couple of local changes...\n\nNow, that's the first question: suppose I want to build kernels for about \n4 machines. Do you __really__ clone the whole tree 4 times??? And then I \nwant try new versions for the same 4 machines without deleting the first \nones - 4 more clones??? Now, my copy of Linus' tree was ATM 1.5GiB big... \nSlowly it's getting scary. Ok, if I build all that stuff on one \nfilesystem, I can use --local to use hard links, right? But is it REALLY \nwhat everybody does?\n\nThe next thing is - I don't need all versions since 2.6.x in every copy I \nuse to compile / test / hack - in most cases I only compare to the basis \nversion, from which I branched. I might pull further updates into this \nrepository, merge, etc., but I don't need all PAST commits! Can I clone \nstarting from version x?\n\nOk, enough for starters:-)\n\nThanks\nGuennadi\n---\nGuennadi Liakhovetski\n"},{"id":"38352","messageId":"20070329211616.GH6143@fieldses.org","threadId":"7477","inReplyTo":"Pine.LNX.4.60.0703292225100.10351@poirot.grange","subject":"Re: basics... when reading docs doesn't help","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-03-29T21:16:16Z","receivedAt":"2007-03-29T21:16:16Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Mar 29, 2007 at 10:50:51PM +0200, Guennadi Liakhovetski wrote:\n> Now, my copy of Linus' tree was ATM 1.5GiB big... Slowly it's getting\n> scary.\n\nOn my laptop:\n\n[bfields@pad linux]$ du -hs .\n1.5G .\n[bfields@pad linux]$ du -hs .git\n334M .git\n\nSo it's mostly the checked out working directory and build\nstuff.\n\nIf you really need a ton of build trees then you might just want to do\ncp -al or something.\n\n--b.\n"},{"id":"38355","messageId":"7vabxv3fnx.fsf@assigned-by-dhcp.cox.net","threadId":"7477","inReplyTo":"20070329211616.GH6143@fieldses.org","subject":"Re: basics... when reading docs doesn't help","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-29T21:26:10Z","receivedAt":"2007-03-29T21:26:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Thu, Mar 29, 2007 at 10:50:51PM +0200, Guennadi Liakhovetski wrote:\n>> Now, my copy of Linus' tree was ATM 1.5GiB big... Slowly it's getting\n>> scary.\n>\n> On my laptop:\n>\n> [bfields@pad linux]$ du -hs .\n> 1.5G .\n> [bfields@pad linux]$ du -hs .git\n> 334M .git\n>\n> So it's mostly the checked out working directory and build\n> stuff.\n>\n> If you really need a ton of build trees then you might just want to do\n> cp -al or something.\n\nHow about suggesting \"clone -l -s\"?\n"},{"id":"38356","messageId":"20070329214654.GI6143@fieldses.org","threadId":"7477","inReplyTo":"7vabxv3fnx.fsf@assigned-by-dhcp.cox.net","subject":"Re: basics... when reading docs doesn't help","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-03-29T21:46:54Z","receivedAt":"2007-03-29T21:46:54Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Mar 29, 2007 at 02:26:10PM -0700, Junio C Hamano wrote:\n> \"J. Bruce Fields\" writes:\n> \n> > On Thu, Mar 29, 2007 at 10:50:51PM +0200, Guennadi Liakhovetski wrote:\n> >> Now, my copy of Linus' tree was ATM 1.5GiB big... Slowly it's getting\n> >> scary.\n> >\n> > On my laptop:\n> >\n> > [bfields@pad linux]$ du -hs .\n> > 1.5G .\n> > [bfields@pad linux]$ du -hs .git\n> > 334M .git\n> >\n> > So it's mostly the checked out working directory and build\n> > stuff.\n> >\n> > If you really need a ton of build trees then you might just want to do\n> > cp -al or something.\n> \n> How about suggesting \"clone -l -s\"?\n\nIf you really want to share as much as possible, then I guess you want\nto share the working trees too, since (as evidenced above), they're at\nleast as large as the compressed history.\n\nThough actually on a second look, clone -l -s produces something that's\nonly 377M. I hadn't realized how much space the build output takes up.\nSo judging from du the 1.5G Guennadi Liakhovetski mentions above seems\nto break down into something like:\n\n\t330M .git\n\t380M working tree\n\t750M build output\n\n--b.\n"},{"id":"38361","messageId":"Pine.LNX.4.60.0703292354100.10351@poirot.grange","threadId":"7477","inReplyTo":"20070329214654.GI6143@fieldses.org","subject":"Re: basics... when reading docs doesn't help","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2007-03-29T22:13:02Z","receivedAt":"2007-03-29T22:13:02Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"On Thu, 29 Mar 2007, J. Bruce Fields wrote:\n\n> On Thu, Mar 29, 2007 at 02:26:10PM -0700, Junio C Hamano wrote:\n> > \n> > How about suggesting \"clone -l -s\"?\n\nYes, but how do \"advanced git users\" kernel developers work? Do they just \ndo 1 clone and build / clean every time they want to test another \nconfiguration / arch, or do they clone -l or what? Do they create branches \nfor each development thread, then pull / push between trees?...\n\n> If you really want to share as much as possible, then I guess you want\n> to share the working trees too, since (as evidenced above), they're at\n> least as large as the compressed history.\n\nBut I don't want to re-build. Apart from i386 I build for a couple of ARM \nand PPC targets too...\n\n> Though actually on a second look, clone -l -s produces something that's\n> only 377M. I hadn't realized how much space the build output takes up.\n> So judging from du the 1.5G Guennadi Liakhovetski mentions above seems\n> to break down into something like:\n> \n> \t330M .git\n> \t380M working tree\n> \t750M build output\n\nStrange. Is my git 1.4.0 criminally broken? I have a clone of Linus' tree \non a USB disk on ext3 without any objects, which I just cloned at some \npoint and then did a couple of pulls from the same source. Now\n\n1545084 /mnt/sda2/kernel-git/linux-2.6/\n1255084 /mnt/sda2/kernel-git/linux-2.6/.git\n\nInterestingly, both end up with 5084. For comparison:\n\n465044 /mnt/sda2/kernel-git/powerpc\n174980 /mnt/sda2/kernel-git/powerpc/.git\n\nBut that's a freshly cloned tree, without any pulls. I re-cloned it, \nbecause the tree I had earlier had the problem with each pull:\n\nUnpacking 12452 objects\n 100% (12452/12452) done\n* refs/heads/origin: does not fast forward to branch 'master' of \ngit://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc;\n not updating.\n\nWonderful and strange git world...\n\nThanks\nGuennadi\n---\nGuennadi Liakhovetski\n"},{"id":"38363","messageId":"vpq648jit25.fsf@olympe.imag.fr","threadId":"7477","inReplyTo":"20070329211616.GH6143@fieldses.org","subject":"Re: basics... when reading docs doesn't help","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-03-29T22:27:46Z","receivedAt":"2007-03-29T22:27:46Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> If you really need a ton of build trees then you might just want to do\n> cp -al or something.\n\nBut be careful that this is a potentially dangerous optimization : if\nyou ever use a command that doesn't break hardlinks (for example\n\"echo foo >> file\"), the modification is applied to both trees.\n\n-- \nMatthieu\n"},{"id":"38365","messageId":"Pine.LNX.4.64.0703291531030.6730@woody.linux-foundation.org","threadId":"7477","inReplyTo":"Pine.LNX.4.60.0703292354100.10351@poirot.grange","subject":"Re: basics... when reading docs doesn't help","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-29T22:35:29Z","receivedAt":"2007-03-29T22:35:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 30 Mar 2007, Guennadi Liakhovetski wrote:\n> > > \n> > > How about suggesting \"clone -l -s\"?\n> \n> Yes, but how do \"advanced git users\" kernel developers work? Do they just \n> do 1 clone and build / clean every time they want to test another \n> configuration / arch, or do they clone -l or what? Do they create branches \n> for each development thread, then pull / push between trees?...\n\nI suspect it depends on the developer.\n\nI end up just using different branches and switching between them, but \nthen, my branches tend to all be pretty small test-stuff (I only end up \nusing one main branch, since 99% of what I do is merge other peoples stuff \nthat has already gone through a test-cycle).\n\n> But I don't want to re-build. Apart from i386 I build for a couple of ARM \n> and PPC targets too...\n\nYou're probably fine with \"git clone -l -s\" then.\n\n> Strange. Is my git 1.4.0 criminally broken? I have a clone of Linus' tree \n> on a USB disk on ext3 without any objects, which I just cloned at some \n> point and then did a couple of pulls from the same source. Now\n> \n> 1545084 /mnt/sda2/kernel-git/linux-2.6/\n> 1255084 /mnt/sda2/kernel-git/linux-2.6/.git\n\nThe old git that always exploded all pulls and generated lots of loose \nobjects? You can check with \"git count-objects\".\n\nAnd to fix it, just do a \"git gc\" (or with older git versions, the secret \nhandshake is just a simple \"git repack -a -d\").\n\n> But that's a freshly cloned tree, without any pulls. I re-cloned it, \n> because the tree I had earlier had the problem with each pull:\n> \n> Unpacking 12452 objects\n> 100% (12452/12452) done\n> * refs/heads/origin: does not fast forward to branch 'master' of \n> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc;\n> not updating.\n\nSounds like either Paul re-based his tree, or you did some work on your \n\"origin\" branch..\n\n\t\t\tLinus\n"},{"id":"38383","messageId":"20070330024327.GC3198@thunk.org","threadId":"7477","inReplyTo":"Pine.LNX.4.60.0703292354100.10351@poirot.grange","subject":"Re: basics... when reading docs doesn't help","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-03-30T02:43:27Z","receivedAt":"2007-03-30T02:43:27Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Mar 30, 2007 at 12:13:02AM +0200, Guennadi Liakhovetski wrote:\n> On Thu, 29 Mar 2007, J. Bruce Fields wrote:\n> > Though actually on a second look, clone -l -s produces something that's\n> > only 377M. I hadn't realized how much space the build output takes up.\n> > So judging from du the 1.5G Guennadi Liakhovetski mentions above seems\n> > to break down into something like:\n> > \n> > \t330M .git\n> > \t380M working tree\n> > \t750M build output\n\nHmm.... That doesn't look right. My packed .git directory is 156 megs\n(using post git 1.5 and repack.usedeltabaseoffset=true and\ncore.legacyheaders=false).\n\nMy working tree is 287M, and my build output (size of build tree minus\nsources) is 1055M. (This will vary based on .config options, obviously).\n\nThe point though is the size of the .git tree is in the noise compared\nto the size of the object files. I do share the .git repository\nbetween trees; in fact I have a standard \"base\" repository which is\njust a mirror of Linus's tree, and my other kernel repositories have\nan .git/objects/info/alternates file which points at the base\nrepository for maximal sharing.\n\nI could try to share the sources where the source files are identical,\nbut quite frankly, it's just never been worth the effort. After all,\nwhen you have a 100gig laptop drive, 287 megs isn't that much, and\nit's noise compared to the size of my object files.\n\n> Strange. Is my git 1.4.0 criminally broken? I have a clone of Linus' tree \n> on a USB disk on ext3 without any objects, which I just cloned at some \n> point and then did a couple of pulls from the same source. \n\nYou really, really, *REALLY* want to upgrade to at least git 1.5.0.\nIt's is *so* much better than git 1.5.0, and it's a lot easier to make\nsure your repository is kept packed, using \"git gc\". \n\n\t\t\t\t\t\t- Ted\n"},{"id":"38392","messageId":"20070330144908.GA15224@fieldses.org","threadId":"7477","inReplyTo":"20070330024327.GC3198@thunk.org","subject":"Re: basics... when reading docs doesn't help","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-03-30T14:49:08Z","receivedAt":"2007-03-30T14:49:08Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Mar 29, 2007 at 10:43:27PM -0400, Theodore Tso wrote:\n> On Fri, Mar 30, 2007 at 12:13:02AM +0200, Guennadi Liakhovetski wrote:\n> > On Thu, 29 Mar 2007, J. Bruce Fields wrote:\n> > > Though actually on a second look, clone -l -s produces something that's\n> > > only 377M. I hadn't realized how much space the build output takes up.\n> > > So judging from du the 1.5G Guennadi Liakhovetski mentions above seems\n> > > to break down into something like:\n> > > \n> > > \t330M .git\n> > > \t380M working tree\n> > > \t750M build output\n> \n> Hmm.... That doesn't look right. My packed .git directory is 156 megs\n> (using post git 1.5 and repack.usedeltabaseoffset=true and\n> core.legacyheaders=false).\n\nI haven't run more than git-gc in a while, because I have local clones\nand didn't want to figure out how to prune. Hm, now that I've looked it\nup:\n\ngit prune -- $(cd ../linux-clone/ && echo $(git-rev-parse --all))\n\njust gets me the git-prune usage message. In fact, contrary to the\nprune man page, git-prune doesn't seem to accept any arguments.\nIsn't this a bug? I'm on 1.5.0.3.31.ge47c.\n\n--b.\n"},{"id":"38403","messageId":"20070330180211.GI16087@alberich.amd.com","threadId":"7477","inReplyTo":"Pine.LNX.4.60.0703292354100.10351@poirot.grange","subject":"Re: basics... when reading docs doesn't help","fromName":"Andreas Herrmann","fromEmail":"andreas.herrmann3@amd.com","sentAt":"2007-03-30T18:02:11Z","receivedAt":"2007-03-30T18:02:11Z","isPatch":false,"sender":{"key":"andreas.herrmann3@amd.com","avatar":null},"body":"On Fri, Mar 30, 2007 at 12:13:02AM +0200, Guennadi Liakhovetski wrote:\n> On Thu, 29 Mar 2007, J. Bruce Fields wrote:\n> \n> > On Thu, Mar 29, 2007 at 02:26:10PM -0700, Junio C Hamano wrote:\n> > > \n> > > How about suggesting \"clone -l -s\"?\n> \n> Yes, but how do \"advanced git users\" kernel developers work? Do they just \n> do 1 clone and build / clean every time they want to test another \n> configuration / arch, or do they clone -l or what? Do they create branches \n> for each development thread, then pull / push between trees?...\n> \n> > If you really want to share as much as possible, then I guess you want\n> > to share the working trees too, since (as evidenced above), they're at\n> > least as large as the compressed history.\n> \n> But I don't want to re-build. Apart from i386 I build for a couple of ARM \n> and PPC targets too...\n\nSeems to be trivial but:\nWhy don't you use \"make O=/foo/bar/arch-config\" to put output\nfiles into separate directories? So you can have one source tree and\nput each different kernel config and arch into a separate output\ndirectory.\n\nAnd if you have different sources for you trees put them into branches.\n\nWhen switching between branches, atime of files are updated accordingly.\nSo even make should be happy with that.\n\nJust one drawback:\nSwitching back and forth between two branches will cause\nrecompilation of sources that differ between that branches -\nalthough nothing might have changed within a branch in the meantime.\n\n(Not that I have used such an setup, yet.\nBut I think that should work.)\n\n\nRegards,\n\nAndreas\n"},{"id":"38404","messageId":"Pine.LNX.4.60.0703301855480.4757@poirot.grange","threadId":"7477","inReplyTo":"Pine.LNX.4.64.0703291531030.6730@woody.linux-foundation.org","subject":"Re: basics... when reading docs doesn't help","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2007-03-30T18:16:57Z","receivedAt":"2007-03-30T18:16:57Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"On Thu, 29 Mar 2007, Linus Torvalds wrote:\n\n> On Fri, 30 Mar 2007, Guennadi Liakhovetski wrote:\n> \n> > Strange. Is my git 1.4.0 criminally broken? I have a clone of Linus' tree \n> > on a USB disk on ext3 without any objects, which I just cloned at some \n> > point and then did a couple of pulls from the same source. Now\n> > \n> > 1545084 /mnt/sda2/kernel-git/linux-2.6/\n> > 1255084 /mnt/sda2/kernel-git/linux-2.6/.git\n> \n> The old git that always exploded all pulls and generated lots of loose \n> objects? You can check with \"git count-objects\".\n\nInstalled 1.5.0.6 and its output of \"git count-objects\" is\n\n180932 objects, 1112656 kilobytes\n\ngit gc removed everything (uh?) and then\n\nlinux-2.6$ du -ks .git\n183040 .git\n\ncool...\n\n> And to fix it, just do a \"git gc\" (or with older git versions, the secret \n> handshake is just a simple \"git repack -a -d\").\n> \n> > But that's a freshly cloned tree, without any pulls. I re-cloned it, \n> > because the tree I had earlier had the problem with each pull:\n> > \n> > Unpacking 12452 objects\n> > 100% (12452/12452) done\n> > * refs/heads/origin: does not fast forward to branch 'master' of \n> > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc;\n> > not updating.\n> \n> Sounds like either Paul re-based his tree, or you did some work on your \n> \"origin\" branch..\n\nIt must be the former then:-) Did I have a chance to re-synchronize \nlocally to be able to pull normally again or was the only way to re-clone?\n\nThanks\nGuennadi\n---\nGuennadi Liakhovetski\n"},{"id":"38406","messageId":"Pine.LNX.4.60.0703302022020.4757@poirot.grange","threadId":"7477","inReplyTo":"20070330180211.GI16087@alberich.amd.com","subject":"Re: basics... when reading docs doesn't help","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2007-03-30T18:24:17Z","receivedAt":"2007-03-30T18:24:17Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"On Fri, 30 Mar 2007, Andreas Herrmann wrote:\n\n> Seems to be trivial but:\n> Why don't you use \"make O=/foo/bar/arch-config\" to put output\n> files into separate directories? So you can have one source tree and\n> put each different kernel config and arch into a separate output\n> directory.\n> \n> And if you have different sources for you trees put them into branches.\n> \n> When switching between branches, atime of files are updated accordingly.\n> So even make should be happy with that.\n> \n> Just one drawback:\n> Switching back and forth between two branches will cause\n> recompilation of sources that differ between that branches -\n> although nothing might have changed within a branch in the meantime.\n\nExactly, and since I have not only different configs, but also different \nversions, and I don't commit all modifications, so... It would be \ndifficult. I think, the setup with \"clone -l -s\" should be the best.\n\nThanks to all for ideas\nGuennadi\n---\nGuennadi Liakhovetski\n"},{"id":"38408","messageId":"Pine.LNX.4.64.0703301126390.6730@woody.linux-foundation.org","threadId":"7477","inReplyTo":"Pine.LNX.4.60.0703301855480.4757@poirot.grange","subject":"Re: basics... when reading docs doesn't help","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-30T18:48:54Z","receivedAt":"2007-03-30T18:48:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 30 Mar 2007, Guennadi Liakhovetski wrote:\n> \n> Installed 1.5.0.6 and its output of \"git count-objects\" is\n> \n> 180932 objects, 1112656 kilobytes\n\nYeah, that is all the loose objects. That's 1.1GB of stuff as loose \nobjects, which also likely means that your tree was not only using up too \nmuch disk-space, it was probably running about ten times slower than than \nit needs to be for many operations.\n\nUsing pack-files ends up speeding up a lot of \"big\" operations a *lot*. If \nall you do is look at individual commits, you'll probably not notice much, \nbut even something as simple as running \"gitk\" with no parameters (which \nwill thus traverse the whole history) should be a *lot* faster after it's \nbeen all re-packed.\n\n> git gc removed everything (uh?) and then\n\nWell, it will generally remove all loose objects, since they get put into \nthe pack-files instead. So it didn't remove \"everything\", but it does \nremove everything that \"git count-objects\" normally counts (if you give \ncount-objects the \"-v\" flag for verbose output, it will talk about packed \nobjects too).\n\n> linux-2.6$ du -ks .git\n> 183040 .git\n> \n> cool...\n\nThat looks about right. Packing generally uses about a tenth of the \ndisk-space of loose objects - both from the use of deltas, and from the \nfact that you don't any disk block fragmentation. And because looking at \nobjects then doesn't require any system calls any more (just the initial \n\"mmap pack and read index\" stuff), it ends up being much faster too, \ndespite the added overhead of doing the whole delta-chain thing.\n\n> > > Unpacking 12452 objects\n> > > 100% (12452/12452) done\n> > > * refs/heads/origin: does not fast forward to branch 'master' of \n> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc;\n> > > not updating.\n> > \n> > Sounds like either Paul re-based his tree, or you did some work on your \n> > \"origin\" branch..\n> \n> It must be the former then:-) Did I have a chance to re-synchronize \n> locally to be able to pull normally again or was the only way to re-clone?\n\nYou need to mark \"refs/heads/origin\" as always following the remote \n\"master\", even if it gets re-based. You do that by adding a \"+\" before \nthe refspec that describes the remote.\n\nThese days, with git-1.5.x, \"git clone\" will do that for you (and make the \nremotes fall under \"refs/remotes/origin/*\" instead - they're considered \nseparate branches from the local branches these days). However, since you \ncreated the repository with an older git version, it still uses the \noriginal format (and even though you upgraded your git binary, it will use \nthe old-fashioned branch format for remote branches and for \nconfiguration).\n\nSo in your case, the remote is probably described by the \n.git/remotes/origin file, and it looks something like\n\n\tURL: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc\n\tPull: master:origin\n\nand you should just change that \"Pull:\" line to have a \"+\" in front of the \nrefspec:\n\n\tURL: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc\n\tPull: +master:origin\n\nwhich tells git that the remote \"master\" branch should now \n*unconditionally* be followed into the local \"origin\" branch when you \npull.\n\n(In a more modern setup, you wouldn't have a .git/remotes/origin file at \nall, insead you would have something like this in the .git/config file:\n\n\t[remote \"origin\"]\n\t\turl = git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc\n\t\tfetch = +refs/heads/*:refs/remotes/origin/*\n\n\t[branch \"master\"]\n\t\tremote = origin\n\t\tmerge = refs/heads/master\n\nwhich means that there is a remote called \"origin\", and all of the remote \nheads in that remote (\"refs/heads/*\") will be fetched into the local \nrepository under \"refs/remotes/origin/*\". And the \"+\" again means that we \ndo this even if it's not a fast-forward, ie we trust the remote \nexplicitly.\n\nSo \"git fetch origin\" will fetch *all* branches from \"origin\" into your \nlocal repository, but to distinguish them from your *own* branches, they \nwill be under .git/refs/remotes/ instead of your \"real\" local branches \nthat are in \".git/refs/heads/. So you can now see the difference between \nyour *local* version of a branch X and the remote version of that same \nbranch by using \"X\" and \"remotes/origin/X\" respectively to describe that \nbranch.\n\nThen, the second part of the above config file means that when you're on \nthe local \"master\" branch and do a \"git pull\", it will fetch it from the \nremote \"origin\", and merge the remote \"refs/heads/master\" branch from that \nremote (the same one that will be fetched into refs/remotes/origin/master \nby a \"git fetch\".\n\nYeah, this is all a bit complex, and it takes a while to wrap your head \naround it, but I have to say, once you do, the git-1.5.x layout really \n*is* very powerful, and it's actually very natural too (but the \"very \nnatural\" part only comes after you have that \"Aaahh!\" moment!)\n\n\t\t\tLinus\n"},{"id":"38410","messageId":"Pine.LNX.4.60.0703302135590.10784@poirot.grange","threadId":"7477","inReplyTo":"Pine.LNX.4.64.0703301126390.6730@woody.linux-foundation.org","subject":"Re: basics... when reading docs doesn't help","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2007-03-30T19:49:20Z","receivedAt":"2007-03-30T19:49:20Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"On Fri, 30 Mar 2007, Linus Torvalds wrote:\n> \n> You need to mark \"refs/heads/origin\" as always following the remote \n> \"master\", even if it gets re-based. You do that by adding a \"+\" before \n> the refspec that describes the remote.\n> \n> These days, with git-1.5.x, \"git clone\" will do that for you (and make the \n> remotes fall under \"refs/remotes/origin/*\" instead - they're considered \n> separate branches from the local branches these days). However, since you \n> created the repository with an older git version, it still uses the \n> original format (and even though you upgraded your git binary, it will use \n> the old-fashioned branch format for remote branches and for \n> configuration).\n> \n> So in your case, the remote is probably described by the \n> .git/remotes/origin file, and it looks something like\n> \n> \tURL: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc\n> \tPull: master:origin\n> \n> and you should just change that \"Pull:\" line to have a \"+\" in front of the \n> refspec:\n> \n> \tURL: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc\n> \tPull: +master:origin\n> \n> which tells git that the remote \"master\" branch should now \n> *unconditionally* be followed into the local \"origin\" branch when you \n> pull.\n> \n> (In a more modern setup, you wouldn't have a .git/remotes/origin file at \n> all, insead you would have something like this in the .git/config file:\n> \n> \t[remote \"origin\"]\n> \t\turl = git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc\n> \t\tfetch = +refs/heads/*:refs/remotes/origin/*\n> \n> \t[branch \"master\"]\n> \t\tremote = origin\n> \t\tmerge = refs/heads/master\n> \n> which means that there is a remote called \"origin\", and all of the remote \n> heads in that remote (\"refs/heads/*\") will be fetched into the local \n> repository under \"refs/remotes/origin/*\". And the \"+\" again means that we \n> do this even if it's not a fast-forward, ie we trust the remote \n> explicitly.\n> \n> So \"git fetch origin\" will fetch *all* branches from \"origin\" into your \n> local repository, but to distinguish them from your *own* branches, they \n> will be under .git/refs/remotes/ instead of your \"real\" local branches \n> that are in \".git/refs/heads/. So you can now see the difference between \n> your *local* version of a branch X and the remote version of that same \n> branch by using \"X\" and \"remotes/origin/X\" respectively to describe that \n> branch.\n> \n> Then, the second part of the above config file means that when you're on \n> the local \"master\" branch and do a \"git pull\", it will fetch it from the \n> remote \"origin\", and merge the remote \"refs/heads/master\" branch from that \n> remote (the same one that will be fetched into refs/remotes/origin/master \n> by a \"git fetch\".\n> \n> Yeah, this is all a bit complex, and it takes a while to wrap your head \n> around it, but I have to say, once you do, the git-1.5.x layout really \n> *is* very powerful, and it's actually very natural too (but the \"very \n> natural\" part only comes after you have that \"Aaahh!\" moment!)\n\nAha, so, that's how it is then! Why hasn't anybody explained this to me \nstrait away?!:-))))\n\nYeah, hopefully, I'll learn to at least use this thing efficiently enough. \nSomeone has to write a book on it though...\n\nAnd, so, it's a pity I cloned Paul's tree yesterday with the \"old\" git. \nAnd from your answer above it seems like some features of the \"new\" git \nwill not be available with this tree, like equally named local and remote \nbranches, etc. There isn't a way to convert such a \"old style\" tree to the \n\"new style\", is there? Not a big deal, will re-clone at some point, maybe \nwhen we get local git mirrors...\n\nMany thanks for taking your time to answer, Linus!\nGuennadi\n---\nGuennadi Liakhovetski\n"},{"id":"38412","messageId":"Pine.LNX.4.64.0703301256230.6730@woody.linux-foundation.org","threadId":"7477","inReplyTo":"Pine.LNX.4.60.0703302135590.10784@poirot.grange","subject":"Re: basics... when reading docs doesn't help","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-30T20:06:11Z","receivedAt":"2007-03-30T20:06:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 30 Mar 2007, Guennadi Liakhovetski wrote:\n> \n> And, so, it's a pity I cloned Paul's tree yesterday with the \"old\" git. \n> And from your answer above it seems like some features of the \"new\" git \n> will not be available with this tree, like equally named local and remote \n> branches, etc. There isn't a way to convert such a \"old style\" tree to the \n> \"new style\", is there? Not a big deal, will re-clone at some point, maybe \n> when we get local git mirrors...\n\nThere's a conversion script to help you convert in place if you care.\n\nLook at the git list for an email that looks something like this:\n\n\tDate: Wed, 14 Mar 2007 02:16:12 -0400\n\tFrom: Shawn O. Pearce \n\tTo: git@vger.kernel.org\n\tSubject: Upgrade to 1.5.0 utility\n\n\tYesterday on #git DrNick wanted a script to update a pre-1.5.0\n\tGit repository to be like a 1.5.0 (and later) style repository.\n\t...\n\nwhich has a script in it to do this (it uses another script that is \nalready in git/contrib/ that just moves all the \".git/remotes\" entries \nas-is from the remotes files into the .git/config file)\n\nI haven't tested it myself, so caveat emptor. But the config file format \nreally isn't *that* complicated - do the conversion with the script, and \nthen just go back and look at .git/config and verify that it looks sane, \nor edit it to match your taste.\n\n\t\tLinus\n"},{"id":"38414","messageId":"20070330202312.GG3198@thunk.org","threadId":"7477","inReplyTo":"Pine.LNX.4.60.0703302135590.10784@poirot.grange","subject":"Re: basics... when reading docs doesn't help","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-03-30T20:23:12Z","receivedAt":"2007-03-30T20:23:12Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Mar 30, 2007 at 09:49:20PM +0200, Guennadi Liakhovetski wrote:\n> Aha, so, that's how it is then! Why hasn't anybody explained this to me \n> strait away?!:-))))\n\nA lot of this is in the git 1.5's User Manual:\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html\n\nSee also the man page for git-remote, or here:\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/git-remote.html\n\n\n> Yeah, hopefully, I'll learn to at least use this thing efficiently enough. \n> Someone has to write a book on it though...\n\nThe user-manual and the git tutorials are pretty good --- just make\nsure you look at the ones that come with git 1.5.0, or the ones at\nhttp://www.kernel.org/pub/software/svm/git/docs (which reflects the\nDocumentation as of the latest development version of git).\n\nThe problem is that there are some tutorials on the web which assume\ngit 1.4.x, or cogito, and that has been listed as a defect by people\nwho have been confused because those tutorials are out of date with\nrespect to modern git.[1]\n\n[1] http://changelog.complete.org/posts/594-More-on-Git,-Mercurial,-and-Bzr.html\n\n> And, so, it's a pity I cloned Paul's tree yesterday with the \"old\" git. \n> And from your answer above it seems like some features of the \"new\" git \n> will not be available with this tree, like equally named local and remote \n> branches, etc. There isn't a way to convert such a \"old style\" tree to the \n> \"new style\", is there? Not a big deal, will re-clone at some point, maybe \n> when we get local git mirrors...\n\nYeah, we need to really make sure the word gets out that new git users\nshould really make sure they are using git 1.5, and not git 1.4.x; it\nis such an improvement in terms of usability over git 1.4.x that there\nreally is no comparison. (Of course, guess what Debian is going to\nship in their soon-to-be-release \"stable\" distribution? git 1.4.4. Sigh...)\n\nIt is possible to get the new style naming, by using the git remote\ncommand. Just do\n\n\tgit remote add origin \n\n...and that will adjust your git configuration file appropriate.\nCheck out the git 1.5.0 release notes, and the git-config man page,\nand there are some other adjustments you can make as well that will\nmake git more efficiently, at the cost of breaking some level of\ncompatibility with git 1.4.x tools which replicate via the \"dumb\" http\nprotocol. But for local development repositories that generally isn't\na concern.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"38415","messageId":"7v7isy1n4z.fsf@assigned-by-dhcp.cox.net","threadId":"7477","inReplyTo":"Pine.LNX.4.60.0703302135590.10784@poirot.grange","subject":"Re: basics... when reading docs doesn't help","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-30T20:39:56Z","receivedAt":"2007-03-30T20:39:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Guennadi Liakhovetski writes:\n\n>> Yeah, this is all a bit complex, and it takes a while to wrap your head \n>> around it, but I have to say, once you do, the git-1.5.x layout really \n>> *is* very powerful, and it's actually very natural too (but the \"very \n>> natural\" part only comes after you have that \"Aaahh!\" moment!)\n>\n> Aha, so, that's how it is then! Why hasn't anybody explained this to me \n> strait away?!:-))))\n\nBecause I and others have explained that to other people on the\nlist a few times already, perhaps? The list archive is your\nfriend.\n\n> .... There isn't a way to convert such a \"old style\" tree to the \n> \"new style\", is there?\n\nThat also can be found in the list archive. I think Shawn\nPearce wrote that script using contrib/remotes2config.sh from\nthe git.git project source tree.\n"},{"id":"38377","messageId":"Pine.LNX.4.60.0703302300430.10784@poirot.grange","threadId":"7477","inReplyTo":"7v7isy1n4z.fsf@assigned-by-dhcp.cox.net","subject":"Re: basics... when reading docs doesn't help","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2007-03-30T21:11:46Z","receivedAt":"2007-03-30T21:11:46Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"On Fri, 30 Mar 2007, Junio C Hamano wrote:\n\n> Guennadi Liakhovetski writes:\n> \n> >> Yeah, this is all a bit complex, and it takes a while to wrap your head \n> >> around it, but I have to say, once you do, the git-1.5.x layout really \n> >> *is* very powerful, and it's actually very natural too (but the \"very \n> >> natural\" part only comes after you have that \"Aaahh!\" moment!)\n> >\n> > Aha, so, that's how it is then! Why hasn't anybody explained this to me \n> > strait away?!:-))))\n> \n> Because I and others have explained that to other people on the\n> list a few times already, perhaps? The list archive is your\n> friend.\n\nEmn, sorry, that was supposed to be a joke...\n\nIn my original post I said something like \"I know, this most probably has \nbeen asked (many times) before, but since the questions are pretty \ngeneric, I don't have a very good idea what to search archives for, but \nany pointer to a thread in archive would be appreciated\". I am greatful \nsomebody took his time to explain a couple of things to me even knowing I \nwill only understand a few percent strait away. And I am usually the first \none to point others to list archives:-) It is easy to search for isp1761, \nbut it is not so easy to search for \"clone multiple trees reuse disk \nspace...\"\n\nI am greatful for any help and I can well understand those who decided not \nto repeat what they've already explained a 100 times before.\n\n> > .... There isn't a way to convert such a \"old style\" tree to the \n> > \"new style\", is there?\n> \n> That also can be found in the list archive. I think Shawn\n> Pearce wrote that script using contrib/remotes2config.sh from\n> the git.git project source tree.\n\nThanks, now this is easy to search!\n\nThanks\nGuennadi\n---\nGuennadi Liakhovetski\n"}]}