Re: repack behaves unexpectedly if called in a bare _subrepo_

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: repack behaves unexpectedly if called in a bare _subrepo_

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:17

Alex Riesen [off-list ref] writes:
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?

Re: repack behaves unexpectedly if called in a bare _subrepo_

From: Alex Riesen <hidden>
Date: 2016-06-15 22:43:17

Junio C Hamano, Sun, Jun 17, 2007 19:22:39 +0200:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help