repack behaves unexpectedly if called in a bare _subrepo_

Alex Riesen· Jun 17, 2007, 15:38 UTC · lore

Just a heads-up. This took me by surprise. And I suppose it will be the same even if the subrepo is a real subproject.

To illustrate:

(
    mkdir super && cd super
    git init
    echo 0 > a; git add a; git commit -m0
    echo 2 >> a; git commit -a -m1
    echo 3 >> a; git commit -a -m2
    cp -a .git sub
    cd sub
    git --bare config --bool core.bare true
    git repack -a -d
)

Unexpectedly, the "super" repo is repacked, even though repack is called from the "sub". To actually repack the repo in the current directory if it is bare, use "git --bare repack ...".

This kind of makes core.bare pointless: can't rely on it anyway.

Junio C Hamano· Jun 17, 2007, 17:22 UTC · re: Alex Riesen · lore

Re: repack behaves unexpectedly if called in a bare _subrepo_

Alex Riesen <raa.lkml@gmail.com> writes:

Show 16 quoted lines

> Just a heads-up. This took me by surprise. And I suppose it will be
> the same even if the subrepo is a real subproject.
>
> To illustrate:
>
> (
>     mkdir super && cd super
>     git init
>     echo 0 > a; git add a; git commit -m0
>     echo 2 >> a; git commit -a -m1
>     echo 3 >> a; git commit -a -m2
>     cp -a .git sub
>     cd sub
>     git --bare config --bool core.bare true
>     git repack -a -d
> )

I think what is happening is that in that bare repository 'sub', the sequence we find where a git repository is is defined so that the current directory is checked way after "one of my parents with .git/ subdirectory" check.

If super (a directory) has a subproject sub as its subproject, then you would be copying .git to sub/.git, not sub/, wouldn't you? What are you trying to achieve?

Alex Riesen· Jun 17, 2007, 19:27 UTC · re: Junio C Hamano · lore

Re: repack behaves unexpectedly if called in a bare _subrepo_

Junio C Hamano, Sun, Jun 17, 2007 19:22:39 +0200:

Show 21 quoted lines

> > Just a heads-up. This took me by surprise. And I suppose it will be
> > the same even if the subrepo is a real subproject.
> >
> > To illustrate:
> >
> > (
> >     mkdir super && cd super
> >     git init
> >     echo 0 > a; git add a; git commit -m0
> >     echo 2 >> a; git commit -a -m1
> >     echo 3 >> a; git commit -a -m2
> >     cp -a .git sub
> >     cd sub
> >     git --bare config --bool core.bare true
> >     git repack -a -d
> > )
> 
> I think what is happening is that in that bare repository 'sub',
> the sequence we find where a git repository is is defined so
> that the current directory is checked way after "one of my
> parents with .git/ subdirectory" check.

Yes, that's what I found. Couldn't convince myself it could be wrong, feels right to me.

> If super (a directory) has a subproject sub as its subproject,
> then you would be copying .git to sub/.git, not sub/, wouldn't
> you?

Yes, very likely. But it is not a super project in subproject sense, and why? Is there a reason I can't have a bare subproject?

> What are you trying to achieve?

I mirror some projects I am interested in. There is a directory where all the mirrors are: ~/src. It contains the git/git-svn/git-cvs repositories _and_ the scripts which do the mirroring:

$ ls -a ./ gitk/ motion.gitsvn/ uclibc.gitsvn/ ../ gnulib.git/ moto4lin/ udev/ busybox.gitsvn/ gpsbabel.git/ mutt/ udhcp.gitsvn/ coreutils.git/ historic/ rt2500/ update-gits* count-git-objects* .htaccess sparse/ use-src/ dclock/ iproute2.git/ sunset/ wireless-2.6.git/ git/ klibc/ tig/ .git/ linux.git/ torsmo/ .gitignore mimesplit3/ tuner/

The super in my example is this ~/src, and it keeps track of changes to the scripts (some mirrors can be complicated, so I wanted to be prepared). Felt kind of natural to do it this way. Until I tried to repack the mirrored repos, and it didn't work as I expected. The repos are not tracked as subprojects (in fact, they're .gitignored). There is no point for me to have working directories for the mirrors: it is my home server, if I do something, I do it elsewhere.

It is not exactly a "problem", and anyway there is a couple of solutions (pass --bare, create <mirror>/.git, for instance), I just fall into it and though it'd be a good idea to let others know.