From: Alex Riesen <raa.lkml@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: repack behaves unexpectedly if called in a bare _subrepo_
Date: Sun, 17 Jun 2007 21:27:26 +0200 [thread overview]
Message-ID: <20070617192726.GC2763@steel.home> (raw)
In-Reply-To: <7vir9mzeao.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano, Sun, Jun 17, 2007 19:22:39 +0200:
> > 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.
prev parent reply other threads:[~2007-06-17 19:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-17 15:38 repack behaves unexpectedly if called in a bare _subrepo_ Alex Riesen
2007-06-17 17:22 ` Junio C Hamano
2007-06-17 19:27 ` Alex Riesen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070617192726.GC2763@steel.home \
--to=raa.lkml@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox