{"thread":{"id":"8628","subject":"repack behaves unexpectedly if called in a bare _subrepo_","startedAt":"2007-06-17T15:38:10Z","lastAt":"2007-06-17T19:27:26Z","messageCount":3,"participants":["Alex Riesen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45225","messageId":"20070617153810.GB2763@steel.home","threadId":"8628","inReplyTo":null,"subject":"repack behaves unexpectedly if called in a bare _subrepo_","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-17T15:38:10Z","receivedAt":"2007-06-17T15:38:10Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Just a heads-up. This took me by surprise. And I suppose it will be\nthe same even if the subrepo is a real subproject.\n\nTo illustrate:\n\n(\n    mkdir super && cd super\n    git init\n    echo 0 > a; git add a; git commit -m0\n    echo 2 >> a; git commit -a -m1\n    echo 3 >> a; git commit -a -m2\n    cp -a .git sub\n    cd sub\n    git --bare config --bool core.bare true\n    git repack -a -d\n)\n\nUnexpectedly, the \"super\" repo is repacked, even though repack is\ncalled from the \"sub\". To actually repack the repo in the current\ndirectory if it is bare, use \"git --bare repack ...\".\n\nThis kind of makes core.bare pointless: can't rely on it anyway.\n"},{"id":"45233","messageId":"7vir9mzeao.fsf@assigned-by-dhcp.pobox.com","threadId":"8628","inReplyTo":"20070617153810.GB2763@steel.home","subject":"Re: repack behaves unexpectedly if called in a bare _subrepo_","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-17T17:22:39Z","receivedAt":"2007-06-17T17:22:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> Just a heads-up. This took me by surprise. And I suppose it will be\n> the same even if the subrepo is a real subproject.\n>\n> To illustrate:\n>\n> (\n>     mkdir super && cd super\n>     git init\n>     echo 0 > a; git add a; git commit -m0\n>     echo 2 >> a; git commit -a -m1\n>     echo 3 >> a; git commit -a -m2\n>     cp -a .git sub\n>     cd sub\n>     git --bare config --bool core.bare true\n>     git repack -a -d\n> )\n\nI think what is happening is that in that bare repository 'sub',\nthe sequence we find where a git repository is is defined so\nthat the current directory is checked way after \"one of my\nparents with .git/ subdirectory\" check.\n\nIf super (a directory) has a subproject sub as its subproject,\nthen you would be copying .git to sub/.git, not sub/, wouldn't\nyou?  What are you trying to achieve?\n"},{"id":"45239","messageId":"20070617192726.GC2763@steel.home","threadId":"8628","inReplyTo":"7vir9mzeao.fsf@assigned-by-dhcp.pobox.com","subject":"Re: repack behaves unexpectedly if called in a bare _subrepo_","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-17T19:27:26Z","receivedAt":"2007-06-17T19:27:26Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Sun, Jun 17, 2007 19:22:39 +0200:\n> > Just a heads-up. This took me by surprise. And I suppose it will be\n> > the same even if the subrepo is a real subproject.\n> >\n> > To illustrate:\n> >\n> > (\n> >     mkdir super && cd super\n> >     git init\n> >     echo 0 > a; git add a; git commit -m0\n> >     echo 2 >> a; git commit -a -m1\n> >     echo 3 >> a; git commit -a -m2\n> >     cp -a .git sub\n> >     cd sub\n> >     git --bare config --bool core.bare true\n> >     git repack -a -d\n> > )\n> \n> I think what is happening is that in that bare repository 'sub',\n> the sequence we find where a git repository is is defined so\n> that the current directory is checked way after \"one of my\n> parents with .git/ subdirectory\" check.\n\nYes, that's what I found. Couldn't convince myself it could be wrong,\nfeels right to me.\n\n> If super (a directory) has a subproject sub as its subproject,\n> then you would be copying .git to sub/.git, not sub/, wouldn't\n> you?\n\nYes, very likely. But it is not a super project in subproject sense,\nand why? Is there a reason I can't have a bare subproject?\n\n> What are you trying to achieve?\n\nI mirror some projects I am interested in. There is a directory where\nall the mirrors are: ~/src. It contains the git/git-svn/git-cvs\nrepositories _and_ the scripts which do the mirroring:\n\n$ ls -a\n./                  gitk/          motion.gitsvn/  uclibc.gitsvn/\n../                 gnulib.git/    moto4lin/       udev/\nbusybox.gitsvn/     gpsbabel.git/  mutt/           udhcp.gitsvn/\ncoreutils.git/      historic/      rt2500/         update-gits*\ncount-git-objects*  .htaccess      sparse/         use-src/\ndclock/             iproute2.git/  sunset/         wireless-2.6.git/\ngit/                klibc/         tig/\n.git/               linux.git/     torsmo/\n.gitignore          mimesplit3/    tuner/\n\nThe super in my example is this ~/src, and it keeps track of changes\nto the scripts (some mirrors can be complicated, so I wanted to be\nprepared). Felt kind of natural to do it this way. Until I tried to\nrepack the mirrored repos, and it didn't work as I expected. The repos\nare not tracked as subprojects (in fact, they're .gitignored).\nThere is no point for me to have working directories for the mirrors:\nit is my home server, if I do something, I do it elsewhere.\n\nIt is not exactly a \"problem\", and anyway there is a couple of\nsolutions (pass --bare, create <mirror>/.git, for instance), I just\nfall into it and though it'd be a good idea to let others know.\n"}]}